Проверяется возможность недопустимого воздействия на ПО и данные через интерфейс ПО (СИ).
С помощью программных средств выполняются все функции ПО, подлежащие метрологическому контролю (аттестации), и определяется их соответствие представленной документации. Исследуются меню, подменю, диалоги ПО с целью выявления не соответствующих документации функций, параметров и команд.
Проверяется фильтрация ввода данных через интерфейс и возможность введения недопустимых данных.
При высокой жесткости испытания проводятся на основе анализа исходного кода ПО. При этом:
— выявляются недокументированные функции, процедуры, параметры, переменные, команды и их использование в ПО;
— проверяется соответствие действия вводимых команд (с помощью диалогов, командной строки и т.д.) представленной документации.
Под проверкой соответствия понимается проверка конкретного ПО на соответствие тому типу, который был утвержден (зафиксирован) при его аттестации, если такая аттестация ранее проводилась, а также проверка методов и способов идентификации.
Идентификация, аутентификация и авторизация простыми словами
При низкой и средней жесткости испытаний проверка соответствия утвержденному типу проводится на основе анализа представленной документации, а также с использованием программных средств. При этом может приниматься во внимание заявление заказчика аттестации об отсутствии изменений и модификаций части ПО, подлежащей метрологическому контролю (аттестации).
При низкой и средней жесткости испытаний методы и средства идентификации ПО проверяются на основе документации и выполнения функциональных испытаний (тестирования) ПО.
На основе документации проверяется описание реализованного метода идентификации и способа работы с ним. В случае разделения ПО на программном уровне устанавливается соответствие метода идентификации принципу разделения ПО.
На основе анализа документации получают информацию обо всех частях (модулях) ПО (с учетом его разделения), охватываемых идентификацией. Все части ПО, подлежащие метрологическому контролю (аттестации) должны быть охвачены алгоритмом идентификации.
Оценивается соответствие метода идентификации уровню требуемой защиты.
Проверяется наличие номинального значения, идентифицирующего ПО (номер версии, контрольная сумма и др.). Номинальное значение идентификации ПО вносится в свидетельство об аттестации.
Проверяется функция идентификации ПО, например, выводом номера версии на экран.
При высокой жесткости испытаний проводятся дополнительные испытания на основе анализа исходного кода ПО. При этом устанавливается:
— охват идентификацией всех частей ПО, подлежащих метрологическому контролю (аттестации), например, формирование номинального закрепляемого значения идентификации;
— охват идентификацией частей ПО, не подлежащих метрологическому контролю (аттестации);
— соответствие метода идентификации представленной документации.
Источник: studopedia.su
Что такое системы идентификации личности и для чего они нужны
Польза и вред инфракрасного обогревателя (331053)
Среди электрических обогревателей, которые мы используем в быту, наиболее популярными сейчас становятся инфракрасные нагреватели. Они очень широко рекламируются в Интернете и в газетах. Говорят, что они намного эффективнее масляных радиаторов и тепловентиляторов. Меньше потребляют энергии, не сжигают кислород и т.д. Главное – они совершенно не вредные, никакого отрицательного воздействия на организм человека не оказывают. Далее
Почему горячая вода замерзает быстрее, чем холодная? (220485)
Это действительно так, хотя звучит невероятно, т.к в процессе замерзания предварительно нагретая вода должна пройти температуру холодной воды. Парадокс известен в мире, как «Эффект Мпембы». Далее
Вредно ли разогревать пищу в микроволновке? (203692)
Одна моя знакомая отказывается есть пищу, которую кто-то разогрел в микроволновой печи. Всему виной — страшилки в Интернете. Далее
451 градус по Фаренгейту, температура возгорания бумаги? (199468)
451 градус по Фаренгейту. Это название знаменитой книги Рэя Брэдбери. На языке оригинала звучит так: ‘Fahrenheit 451: The Temperature at which Book Paper Catches Fire, and Burns’. Действительно ли при этой температуре начинают гореть книги? Далее
Контролируйте температуру приготовления мяса! (188088)
При приготовлении сырого мяса, особенно, домашней птицы, рыбы и яиц необходимо помнить, что только нагревание до надлежащей температуры убивают вредные бактерии. Далее
Основные разделы
Идентификация программного обеспечения при испытаниях средств измерений в целях утверждения их типа
Сокращения, используемые в тексте: ПО – программное обеспечение; СИ – средство измерений; МХ – метрологические характеристики; БД – база данных; СУБД – система управления базами данных; ГЦИ – государственный центр испытаний.
Единообразный подход к любому ПО любого СИ, принятый в МИ 3286 и МИ 3290, стал камнем преткновения, серьёзно затрудняющим проведение ГЦИ СИ испытаний СИ, в конструкции которых тем или иным образом используется ПО. Критика (особенно действующих нормативных документов) – вещь нерациональная, если не предлагать альтернативу. Исходя из этого убеждения в приведённом ниже тексте я буду стараться воздерживаться от критических замечаний и излагать свою точку зрения на один из аспектов испытаний ПО при утверждении типа СИ – его идентификацию.
Затруднения при испытаниях ПО СИ начинаются с отсутствия в МИ терминов и определений, связанных с классификацией ПО и его окружения. Ниже приведены термины и определения для отсутствующих в МИ понятий, которые кажутся важными для испытаний ПО СИ.
Встроенное ПО СИ – исполняемое ПО, размещённое в запоминающих устройствах, расположенных внутри корпуса СИ.
Интегрированное ПО СИ – встроенное ПО СИ, недоступное для изменений через имеющиеся у СИ интерфейсы.
Загружаемое ПО СИ – встроенное ПО СИ, для которого в процессе эксплуатации СИ предусмотрена возможность записи через имеющиеся у СИ интерфейсы в запоминающие устройства, расположенные внутри корпуса СИ.
Автономное ПО – исполняемое ПО, размещённое вне корпуса СИ.
Примечание:
Определения встроенное ПО СИ, интегрированное ПО СИ, загружаемое ПО СИ, автономное ПО СИ могут использоваться также и в отношении части ПО, например: интегрированная часть ПО СИ, автономная часть ПО СИ.
Аппаратное окружение ПО СИ – комплекс аппаратных средств, с использованием ресурсов которого исполняется ПО СИ.
Программное окружение ПО СИ – комплекс программных средств, с использованием ресурсов которого исполняется ПО СИ.
Примечания:
1. Определения аппаратное окружение ПО СИ и программное окружение ПО СИ могут использоваться также и в отношении части ПО, например: аппаратное окружение интегрированной части ПО СИ, программное окружение автономной части ПО СИ.
2. Термин программное окружение ПО СИ не имеет смысла в случае интегрированного ПО СИ.
Входные данные – информация на входе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.
Конфигурационные данные – изменяемая в процессе эксплуатации СИ информация, влияющая на функционирование исполняемого ПО СИ.
Выходные данные – информация на выходе процесса, в т.ч. исполняемого ПО, алгоритма и т.п.
Поток данных – абстракция, служащая для описания поступающих последовательно во времени входных данных или генерируемых последовательно во времени выходных данных.
Допускаемая нагрузка ПО СИ – объём потока входных данных, не приводящий к изменению функциональных характеристик исполняемого ПО СИ.
Идентификация интегрированного ПО
В качестве одной из причин необходимости идентификации ПО СИ, включая интегрированное ПО, авторы МИ называют потенциальную недобросовестность изготовителя, в силу которой он может попытаться изменить ПО с корыстной целью (видимо, это связано с предыдущей сферой деятельности авторов МИ – игровыми автоматами). Непонятно, почему такое внимание уделено именно ПО СИ – ведь изготовитель ровно с тем же эффектом может изменить схемотехнику СИ и это никак специально не контролируется. Более того, существует практика того, что изготовитель имеет право вносить в конструкцию СИ изменения после подтверждения в рамках «внутренних» типовых испытаний факта того, что вносимые изменения не влекут за собой ухудшения потребительских свойств изделия, в т.ч. МХ СИ. Функционально ПО – это такая же часть конструкции СИ, как, например инструментальный усилитель или АЦП, а лишать производителя права улучшать конструкцию СИ не кажется вполне законным.
Вдобавок, исполняемый код интегрированного ПО СИ часто размещён в заблокированной для чтения памяти программ микроконтроллера, что делает процедуру идентификации ПО бессмысленной с точки зрения контроля за добросовестностью изготовителя. Необходимой и достаточной гарантией того, что интегрированное ПО конкретного СИ аутентично экземпляру ПО СИ, представленного на испытания в целях утверждения типа, является целостность пломбы, ограничивающей доступ к размещённому внутри корпуса СИ аппаратному окружению интегрированного ПО, вкупе с подтверждённым при поверке соответствием МХ СИ установленным требованиям. С этой точки зрения для интегрированного ПО в описании типа средства измерений таблица с идентификационными признаками ПО не должна быть обязательной.
Исключение обязательных требований идентификации интегрированного ПО СИ избавит и изготовителей, и испытателей от бессмысленных «проверок ради проверок», от ненужных затрат средств и времени на реализацию механизмов, которые заведомо бесполезны.
Идентификация загружаемого ПО
Отдельный комплекс проблем связан с идентификацией загружаемого ПО СИ, к которому, в частности, могут быть отнесены компоненты многих систем SCADA. В случае такого ПО на передний план выходят дополнительные вопросы, связанные не столько с самим загружаемым ПО, сколько с его программным окружением, включающем как минимум загрузчик и среду исполнения.
Загружаемое ПО может вовсе не иметь исполняемого кода в привычном понимании, представляя собой набор конфигурационных данных – «проект», который воспроизводит необходимую мнемосхему вместе с параметрами её функционирования. В этом случае в одном массиве или базе данных могут храниться как неизменные данные, для которых может быть каким-либо образом получен цифровой идентификатор типа значения контрольной хэш-функции, так и изменяющиеся во времени данные – результаты измерений и параметры технологического процесса. Для осуществления контроля соответствия такого ПО экземпляру ПО, представленному на испытания в целях утверждения типа СИ, как один из вариантов, может быть проведено тщательное программное разделение, затем созданы специальные программные сценарии для выделения метрологически значимых неизменных данных, преобразования их в непрерывные последовательности и последующего вычисления для этих последовательностей значений контрольной хэш-функции. Одновременно должны быть применены средства идентификации текущей среды исполнения и загрузчика, так как только вместе эти компоненты точно воспроизводят необходимую функциональность ПО СИ. Очевидно, что этот путь требует значительных затрат средств и времени.
Каждый конкретный случай загружаемого ПО СИ должен рассматриваться индивидуально с точки зрения поиска наиболее экономически целесообразного решения задачи подтверждения его целостности и подлинности. Не факт, что идентификационные признаки загружаемого ПО удастся свести в таблицу подобную приведённой в МИ 3290.
Идентификация автономного ПО
При рассмотрении сопровождающего СИ автономного ПО сперва следует изучить вопрос о том, какую задачу это ПО решает. ПО СИ – это часть его конструкции. Независимо от реализованного «внутри» СИ метода измерений, СИ по определению (5.10, 6.2, 8.1 РМГ 29) решает измерительную задачу так, что результат измерений на его выходе – это результат прямых измерений, даже если в дальнейшем проверка этих результатов измерений осуществляется косвенным методом.
Автономным ПО СИ следует считать только ту часть автономного ПО, которое непосредственно участвует в получении результата измерений в виде показаний СИ (6.43 РМГ 29). Та часть автономного ПО, которая занимается обработкой уже полученных результатов прямых измерений с целью получения на их основе результатов косвенных или совокупных измерений, на самом деле должна быть отнесена к программам обработки результатов измерений. Задача установления показателей точности этих результатов, включающая в себя в том числе идентификацию используемого ПО, решается соответствующей методикой измерений (ГОСТ Р 8.563). «Притягивание за уши» для решения этой задачи каких-то особенных процедур вроде обособленной «аттестации ПО» ? это попытка изобрести велосипед.
Для автономного ПО СИ и программ обработки результатов измерений различаются существенные требования к окружению. В первом случае, как правило, существенны требования как к программному, так и к аппаратному окружению, во втором – только к программному окружению. Во многих случаях, например, когда автономное ПО СИ формирует временные диаграммы управления процессом измерений, аппаратное и программное окружение могут оказывать влияние на функционирование автономного ПО СИ и, как следствие, на МХ СИ. В связи с этим следует отметить, что реализация описанного в ГОСТ Р 8.654 механизма программного разделения автономного ПО СИ на метрологически значимую и незначимую части будет успешной только тогда, когда установлено влияние ПО СИ на МХ СИ при любых разрешённых условиях применения в смысле аппаратного и программного окружения, включая проверку допускаемой нагрузки ПО СИ.
Вариант таблицы с идентификационными признаками ПО СИ, предлагаемый МИ 3286 представляется неудобным, поскольку не связан со структурой автономного ПО СИ и структурой его информационного взаимодействия с окружением.
Идентификация автономного ПО СИ при проведении испытаний в целях утверждения типа СИ должна включать идентификацию аппаратного и программного окружения, например, в виде, изложенном ниже.
Должны быть однозначно установлены требования к ОС, использование которых необходимо для правильного функционирования автономного ПО СИ. Сведения об ОС можно указать в таблице по форме таблицы 1.
Таблица 1 – Сведения об ОС
Должен быть однозначно установлен перечень программ – драйверов устройств, использование которых необходимо для правильного функционирования автономного ПО СИ. Для каждого драйвера устройства желательно указать характеристики, перечисленные в таблице 2.
Таблица 2 – Перечень драйверов устройств
Должен быть однозначно установлен перечень прикладных программ, использование которых необходимо для правильного функционирования автономного ПО СИ. Для каждой прикладной программы необходимо установить (указать) характеристики, перечисленные в таблице 3.
Таблица 3 – Перечень прикладных программ
Примечание:
В большинстве случаев СУБД относятся к прикладным программам, тогда как некоторые хранимые процедуры и таблицы БД могут быть классифицированы как часть автономного ПО СИ и конфигурационные данные, влияющие на результаты измерений. В таком случае возникает необходимость провести разделение метрологически значимой и не значимой частей БД.
После идентификации окружения, необходимо однозначно установить состав автономного ПО СИ с логическим разделением его на модули по функциональному назначению. Для каждого модуля желательно указать характеристики, перечисленные в таблице 4, а также состав в виде перечня физических объектов файловой системы (файлов) со своими собственными характеристиками, как показано в таблице 5.
Таблица 4 – Перечень программных модулей автономного ПО СИ
Таблица 5 – Характеристики программного модуля «Х»
В сопроводительной документации автономного ПО СИ, кроме прочего, должен быть описан способ его конфигурирования. Конфигурационные данные, очевидно, также являются объектом, в каком-то виде (с учётом «изменчивой» природы) подлежащим идентификации и защите от несанкционированного изменения.
Вместо заключения хотел бы предложить заинтересованным специалистам публично высказать здесь своё мнение по вопросам идентификации ПО СИ при испытаниях в целях утверждения типа, а также вопросам проверки защиты ПО СИ и вопросам оценки влияния ПО на МХ СИ.
Источник: temperatures.ru
Идентификация программы-клиента
Доброго времени суток. Сейчас проектирую клиент-серверное приложение по сбору данных с клиентских машин. Клиент написан на си, open source, закачка бинарной сборки возможна из личного кабинета на сайте.
Для идентификации программы-клиента планируется использовать некий токен — рандомное число, порядка 10 байт, которое внедряется в код программы непосредственно перед заливкой на сайт. То-есть факт закачки данного экземпляра привязывает токен к аккаунту клиента.
Сама по себе клиентская часть бесполезна, но зато при этой схеме идентификации есть возможность осуществления банального саботажа — путём запуска экземпляра программы, с подобранным token’ом, на хосте не имеющего отношения к заказчику, при этом она будет слать свою информацию, в итоге на сервере вместо полезной статистики получится информационный мусор. Как вариант, защиту можно усилить вторым токеном передаваемом на этапе инсталяции клиентской части, например mac-адресом. Но что-то мне в этой схеме не нравится, что-то на интуитивном уровне — просто ещё не осознал какие грабли из этого могут получится. Пожалуйста, раскритикуйте данную схему идентификации.
- Вопрос задан более трёх лет назад
- 2847 просмотров
Комментировать
Решения вопроса 0
Ответы на вопрос 3
навскидку: я бы новый токен при первой сессии привязывал к ip адресу, а несовпадение пары токен-ip отфильтровывал и как-то с этим разбирался
Ответ написан более трёх лет назад
Нравится 1 2 комментария
фраза «как-то с эти разбирался» порождает больше вопросов, чем даёт ответов) А за мысль — спасибо.
тут просто много вариантов, в зависимости от того насколько критичен авторизованный доступ от клиентов. Если ни на что не влияет — можно завести новую пару и пропускать, если наоборот за этим стоят деньги, то блокировать токен совсем. В любом случае можно письмо кинуть что появиласть новая неавторизованная пара.
Разбираться надо, поскольку это может быть просто смена адреса у клиента. Могут быть совсем экзотичные вещи типа несколько адресов на сервере и падение одного из аплинков.
Источник: qna.habr.com