1, 2. Статистику построили, обновили статью.
3. Поскольку разработчик всегда вовлечен в процесс сертификации (если испытания требуют предоставления доступа к исходным текстам), то взаимодействие выполняется с их ответственным представителем (как правило, менеджер по сертификации), который обеспечивает оперативную передачу сведений об уязвимостях разработчикам (QA, security team и пр.) для их оперативного устранение или получения уточнений.
4. Поскольку разработчик полностью вовлечен в процесс сертификации, более того, заинтересован в быстром ее прохождении, то среднее время реакции разработчика, по нашему опыту, составляет около 5 рабочих дней.
1. Да, изменения вносятся. Как минимум, вносятся новые сведения о контрольных суммах (хэшах) файлов исправленного дистрибутива и исполняемых файлов сертифицируемого ПО.
2. Да, сборка, в том числе сборка исправленных файлов, выполняется либо на территории испытательной лаборатории, либо на территории разработчика в присутствии экспертов. Для уменьшения количества таких выездов наша лаборатория практикует проведения анализа уязвимостей на ранних стадиях испытаний.
К сожалению, все технические подробности попадают под действие NDA между разработчиками и лабораторией. Процедуру в случае выявления – описал в комментарии выше. Принятые меры во всех случаях были связаны с внесением изменений в исходный код программы.
Сертификация конкретной версии ПО с фиксацией в документах конкретного номера сборки и хешей исполняемых файлов достаточно распространённая практика не только в отечественной, но и зарубежных системах сертификации. Выдавать сертификат на что-то абстрактное нельзя – у пользователей должна быть возможность убедиться (например, путем сверки номера сборки или сравнения хешей исполняемых файлов), что они получили от разработчика или поставщика именно сертифицированную версию продукта. При реализации разработчиком ПО процедуры выпуска обновлений и их «легализации» с использованием процедуры инспекционного контроля (а эта процедура налажена у всех крупных российских разработчиков) пользователи сертифицированных продуктов имеют возможность оперативно получать обновления, использование которых не нарушает сертифицированных свойств продукта.
Для подобных случаев (уязвимость обнаружена после получения сертификата) предусмотрена процедура инспекционного контроля (более простая и менее затратная, по сравнению с сертификацией, процедура). Эта процедура предусматривает передачу в испытательную лабораторию доработанного ПО и всех необходимых для поведения испытания материалов. Задача лаборатории – подтвердить, что уязвимость «закрыта», а внесенные исправления не оказали влияния на сертифицированные функции по безопасности. После проверок со стороны испытательной лаборатории и подтверждения со стороны Системы сертификации обновления можно поставлять пользователю (сертификат в этом случае продолжает действовать на обновленную версию продукта). В отдельных случаях (уязвимость «закрывает» критичную уязвимость) разрешается поставлять обновления ПО, не дожидаясь завершения процедуры инспекционного контроля. Случаи отзыва сертификата были (по официальным данным от представителей ФСТЭК России), но это происходило только из-за того, что разработчик не мог исправить уязвимость в течение долгого времени.
1. Техническая информация о найденной уязвимости (тестовый сценарий, подтверждающие материалы) передаются разработчику ПО. Разработчик устраняет уязвимость в исходном коде сертифицируемой программы или, если это возможно, «закрывает» уязвимость компонентами среды функционирования (это бывает достаточно редко). Доработанная программа передается в испытательную лабораторию для верификации исправления и продолжения испытаний. Если доработанная программа успешно проходит оставшиеся проверки, лаборатория делает заключение о соответствии продукта предъявляемым требованиям (это является одним из оснований для оформления сертификата соответствия). Отказ в выдаче сертификата возможен, например, если разработчик сознательно не исправляет уязвимость – на нашей практике такого не случалось. По критичности уязвимостей: все найденные при сертификации уязвимости должны исправляться. Каких-либо официальных уточнений от Системы сертификации в части возможности неустранения некритичных уязвимостей пока нет.
2. Пока нет. Все «КРОВЬ КИШКИ МЯСО», к сожалению, подпадают под действие NDA между лабораторией и разработчиками ПО. Согласовать с разработчиками возможность публичного раскрытия уязвимостей (в совместных пресс-релизах или выступлениях на конференциях) нам пока не удалось, но мы работаем в этом направлении.
Например: R, это язык программирования, в котором масса библиотек для получения данных из соцсетей, ну и, конечно, масса средств обработки и визуализации данных. Удобная оболочка для R: https://www.rstudio.com/products/rstudio/
Александр, хорошая попытка вскрыть международный заговор строителей систем защиты информации!))
По поводу качества первой версии нашего продукта АК-ВС: качество – характеристика относительная и, если решили о ней поговорить, то давайте сравнивать с другими аналогичными решениями, а потом уже выплескивать эмоции. Продукт, как вам известно, не единственный на рынке, также никто не мешает вам разработать собственный инструмент анализа.
Правда, проводить тестирование лучше уже АК-ВС 2, который уже пару лет как представлен на рынке. Если у вас появятся конкретные предложения по улучшению нашего продукта, будем очень признательны.
Спасибо, что вспомнили ГОСТ Р 56939-2016. В его разработке приняло участие 105 компаний и было учтено более 300 замечаний (в том числе и от вашей). Нам о планах сделать его обязательным ничего неизвестно, но мы бы порадовались, так как вложили в ГОСТ массу интеллектуальных усилий: обратите внимание, что он не является переводом западного, а разработан специально под наши реалии. Если его читать внимательно, то можно заметить, что помимо статического анализа кода, реализованного в AppChecker, предусматривается и динамический анализ, и fuzzy-тестирование, и тестирование на проникновение и многие другие меры.
Александр, предлагаем вам, как эксперту скачать AppChecker и попробовать его в деле, и поделиться впечатлением на страницах Хабра, а мы вам подарим наш легендарный перекидной календарь!
Интеграция с СУВ (git, subversion, mercurial) уже есть. Поддержка CI (Jenkins, TeamCity) также есть, но в альфа-версии, релиз планируем в феврале. Так же имеется консольный клиент, с помощью него можно в автоматическом режиме производить анализ и встраивать его в свою систему сборки.
3. Поскольку разработчик всегда вовлечен в процесс сертификации (если испытания требуют предоставления доступа к исходным текстам), то взаимодействие выполняется с их ответственным представителем (как правило, менеджер по сертификации), который обеспечивает оперативную передачу сведений об уязвимостях разработчикам (QA, security team и пр.) для их оперативного устранение или получения уточнений.
4. Поскольку разработчик полностью вовлечен в процесс сертификации, более того, заинтересован в быстром ее прохождении, то среднее время реакции разработчика, по нашему опыту, составляет около 5 рабочих дней.
2. Да, сборка, в том числе сборка исправленных файлов, выполняется либо на территории испытательной лаборатории, либо на территории разработчика в присутствии экспертов. Для уменьшения количества таких выездов наша лаборатория практикует проведения анализа уязвимостей на ранних стадиях испытаний.
2. Пока нет. Все «КРОВЬ КИШКИ МЯСО», к сожалению, подпадают под действие NDA между лабораторией и разработчиками ПО. Согласовать с разработчиками возможность публичного раскрытия уязвимостей (в совместных пресс-релизах или выступлениях на конференциях) нам пока не удалось, но мы работаем в этом направлении.
По поводу качества первой версии нашего продукта АК-ВС: качество – характеристика относительная и, если решили о ней поговорить, то давайте сравнивать с другими аналогичными решениями, а потом уже выплескивать эмоции. Продукт, как вам известно, не единственный на рынке, также никто не мешает вам разработать собственный инструмент анализа.
Правда, проводить тестирование лучше уже АК-ВС 2, который уже пару лет как представлен на рынке. Если у вас появятся конкретные предложения по улучшению нашего продукта, будем очень признательны.
Спасибо, что вспомнили ГОСТ Р 56939-2016. В его разработке приняло участие 105 компаний и было учтено более 300 замечаний (в том числе и от вашей). Нам о планах сделать его обязательным ничего неизвестно, но мы бы порадовались, так как вложили в ГОСТ массу интеллектуальных усилий: обратите внимание, что он не является переводом западного, а разработан специально под наши реалии. Если его читать внимательно, то можно заметить, что помимо статического анализа кода, реализованного в AppChecker, предусматривается и динамический анализ, и fuzzy-тестирование, и тестирование на проникновение и многие другие меры.
Александр, предлагаем вам, как эксперту скачать AppChecker и попробовать его в деле, и поделиться впечатлением на страницах Хабра, а мы вам подарим наш легендарный перекидной календарь!
Ряд алгоритмов, используемых в AppChecker, покрывается следующим патентом:
https://npo-echelon.ru/upload/iblock/7d0/7d01385cccfddcb4eb4c925db3fc3b7a.png
Ну, например компания Эшелон успела с АПК Рубикон )