Применимость методов тестирования ПО к программно-аппаратным СЗИ

Т. М. Каннер

Закрытое акционерное общество «ОКБ САПР», Москва, Россия

В статье рассматривается применимость методов тестирования программного обеспечения к программно-аппаратным средствам защиты информации, выявляются особенности функционирования программно-аппаратных СЗИ в зависимости от их принципа работы, формируются критерии возможности использования существующих методов тестирования ПО для тестирования различных видов программно-аппаратных СЗИ.

Ключевые слова: тестирование, методы тестирования ПО, особенности программно-аппаратных СЗИ, критерии возможности применения методов тестирования ПО для программно-аппаратных СЗИ

Applicability of software testing methods for software and hardware DST

M. Kanner

Closed Joint Stock Company «OKB SAPR», Moscow, Russia

The article considers the applicability of software testing methods for software and hardware data security tools (DST), identifies features of the software and hardware DST according to their operation principles, forms criteria possibility of using existing software testing methods for testing various types of software and hardware DST.

Keywords: testing, software testing methods, features of the software and hardware DST, criteria possibility of using existing software testing methods for testing software and hardware DST.

Применимость методов тестирования программного обеспечения (ПО) к программно-аппаратным средствам защиты информации (СЗИ) целесообразно рассматривать в аспекте существования разных видов тестирования. Обычно принято выделять следующие признаки для классификации видов тестирования [1,2]:

• время проведения;
• позитивность сценариев;
• степень автоматизированности тестирования;
• объект тестирования.

С точки зрения времени проведения тестирования (альфа и бета-тестирование) и позитивности сценариев тестирования (позитивное или негативное тестирование) в целом нет существенной разницы в том, что является предметом тестирования – ПО, программное или программно-аппаратное СЗИ. В связи с этим при выполнении таких видов тестирования любые методы их проведения будут применимы как к программным, так и к программно-аппаратным продуктам (в том числе и СЗИ).

Гораздо интересней рассмотреть виды тестирования, классифицированные по таким признакам как объект тестирования и степень автоматизированности тестирования, так как в этих случаях как раз важно, что является предметом тестирования.

С точки зрения автоматизации тестирование ПО может быть ручным, автоматизированным и полуавтоматизированным [1,2].

В случае ручного тестирования метод тестирования ПО состоит из следующих шагов:

• создание программы и методики испытаний (ПМИ);
• определение входных данных для ПМИ (например, в каких ОС проводится тестирование, какое прикладное ПО дополнительно установлено и т.п.);
• проведение тестирования по ПМИ, которое, в свою очередь, включает:
• выявление некорректного поведения продукта, указывающего на наличие в нем ошибок;
• фиксация проявления ошибок;
• локализация зафиксированных проявлений ошибок (поиск других проявлений и взаимосвязей);
• анализ локализованных проявлений ошибок;
• фиксация ошибок и особенностей;
• анализ полученных результатов тестирования.

Программа и методика испытаний составляется на основании требований, предъявляемых к продукту. Если ПМИ составлена грамотно, то она служит хорошим помощником для тестировщика, описывая четкую последовательность его действий. После выполнения всех пунктов ПМИ на основании полученных результатов можно сделать вывод о соответствии продукта заявленным требованиям, а также оценить найденные ошибки, их критичность и возможность выпуска ПО.

При автоматизированном тестировании используются скрипты, разработанные при помощи специальных программ автоматизации на основании разработанных ПМИ, и повторяющие их проверки автоматизированным способом. В этом случае последовательность шагов точно такая же, как и при ручном тестировании ПО, за исключением того, что его проводит не человек, а автоматизированный тест, им запущенный. Анализ результатов тестирования, в том числе и полученных ошибок, все равно делает человек.

Полуавтоматизированное тестирование включает использование автоматизированных тестов, но с частичным использованием человеческого ресурса, оно используется тогда, когда не получается полностью автоматизировать весь процесс тестирования и часть действий необходимо выполнять вручную. Для тестирования ПО такие ситуации достаточно редкие, и встречаются чаще всего только в том случае, когда по каким-то причинам нет возможности выполнить полную автоматизацию.

Также тестирование ПО (по объекту тестирования) можно условно разделить на следующие группы:

• функциональное (тестирование реализуемого функционала продукта, включая взаимодействие его компонент);
• нефункциональное (нагрузочное, стрессовое тестирование, тестирование удобства использования и т.п.);
• тестирование, связанное с изменениями (регрессионное, санитарное тестирование и т.п.).

Необходимо отметить, что в общем случае при проведении любых видов тестирования ПО применяются следующие обобщенные методы:

1. ручное тестирование по ПМИ (как функциональных, так и нефункциональных требований);
2. автоматизированное тестирование с применением скриптов автоматизации (в основном нагрузочное и стрессовое тестирование, регрессионное и т.п.);
3. полуавтоматизированное в случаях, когда нет возможности полноценно использовать скрипты автоматизации.

Рассмотрим особенности, которые возникают при попытках применения указанных методов проведения тестирования ПО к программно-аппаратным СЗИ на конкретных примерах.

Программно-аппаратные СЗИ, функционирующие до старта ОС

Как правило, СЗИ, функционирующие до старта ОС, представляют собой аппаратный модуль, подключаемый в средство вычислительной техники (СВТ), который либо перехватывает на себя управление до момента старта ОС СВТ, либо с него необходимо инициировать загрузку до (вместо) ОС СВТ. Примером такого СЗИ является средство защиты информации от несанкционированного доступа (НСД) «Аккорд-АМДЗ».

Принцип работы СЗИ НСД «Аккорд-АМДЗ» следующий: контроллер перехватывает управление сразу после выполнения штатного BIOS СВТ и позволяет выполнить дальнейшую загрузку ОС только с заранее определенных постоянных носителей информации и только после прохождения ряда контрольных процедур: идентификации/аутентификации пользователя и проверки целостности технических и программных средств СВТ.

Попробуем применить существующие методы тестирования ПО к тестированию данного СЗИ.

Тестирование «Аккорд-АМДЗ», выполняемое вручную, в общем случае не отличается от ручного тестирования ПО, за исключением того, что необходимо обязательно учитывать в ПМИ некоторые особенности этого СЗИ, такие как [3]:

• сложность фиксации ошибок в функционировании СЗИ (обычно связанная с невозможностью записи большого объема информации в память СЗИ или с тем, что любое возникновение серьезных ошибок, как правило, приводит к перезагрузке СВТ без сохранения каких-либо результатов);
• невозможность в общем случае использовать режим отладки или еще каким-либо образом изменять программную составляющую СЗИ (с сохранением изменений до следующей перезагрузки);
• СЗИ может быть реализовано на базе различных контроллеров (в рассматриваемом случае – Аккорд-5MX, 5.5, 5.5e, GX, GXM, GXMH), то есть входные данные в ПМИ необходимо дополнить различными вариантами исполнения аппаратной базы;
• существование необходимости проведения перекрестного функционального тестирования составляющих программно-аппаратного СЗИ, то есть тестирование их взаимодействия (надежности интерфейса управления, надежности каких-либо аппаратных компонент – флеш-памяти и т.д.);
• существование необходимости проведения тестирования на разнообразном оборудовании (с различными версиями BIOS/UEFI, различными прерываниями и питанием).

При рассмотрении возможности автоматизации тестирования «Аккорд-АМДЗ» сразу же возникает проблема, связанная с тем, что скрипты автоматизации могут функционировать только в ОС с установленным ПО автоматизации (достаточно большого объема с точки зрения объема памяти «Аккорд-АМДЗ»), то есть при наличии среды функционирования скриптов автоматизации. Кроме того невозможно автоматизировать тестирование «Аккорд-АМДЗ» на всём разнообразии оборудования (вручную устанавливая параметры BIOS и т.п., это нарушает идеологию проведения автоматизированных тестов, которые должны проводиться без участия человека. Поэтому автоматизированные тесты для «Аккорд-АМДЗ» в любом случае необходимо дополнять ручной проверкой работоспособности на различном оборудовании.

В соответствии с вышесказанным автоматизация тестирования «Аккорд-АМДЗ» крайне затруднена, возможна только частичная автоматизация и только при выполнении следующих условий:

Условие 1.1. Наличие достаточных условий для работы среды функционирования скриптов автоматизации (работоспособность в среде ОС СЗИ, увеличение объема памяти «Аккорд-АМДЗ», то есть изменение схемотехники).

Условие 1.2. Существование возможности фиксации результатов автоматизированного тестирования (например, с записью на внутренний или внешний носитель информации).

Условие 1.3. наличие скриптов автоматизации перекрестного функционального тестирования составляющих программно-аппаратного СЗИ.

Из описанного видно, что автоматизированные тесты целесообразно проводить на некотором опытном/доработанном образце аппаратной составляющей, удовлетворяющей данным критериям, что, конечно же, не гарантирует точно такой же работоспособности стандартного исполнения аппаратной составляющей.

При рассмотрении тестирования «Аккорд-АМДЗ» несколько с другой стороны, его можно разделить на две части: тестирование исполняемого кода СЗИ отдельно от аппаратной составляющей (например, в среде ОС СВТ, а не СЗИ) и тестирование конечного функционала СЗИ, доступного пользователю (то есть исполняемого кода вместе с аппаратной составляющей).

Исполняемый код СЗИ может быть запущен на выполнение не в среде ОС аппаратного устройства (в нашем случае контроллера Аккорд), а в среде аналогичной ОС, установленной на СВТ. Для исполнения этого кода не в операционной системе, а в виртуальной машине требуется возможность «пробрасывания» аппаратного компонента в конкретной среде виртуализации, что часто бывает невозможно. Таким образом, в рамках ОС СВТ можно автоматизировать процесс проверки корректности исполнения различных модулей, провести нагрузочное и стрессовое тестирование (интерфейса взаимодействия с контроллером и т.п.), проверить корректную работу интерфейса. Но в данном случае не будет ответа на главный вопрос: как будет работать финальный продукт, ведь весь этот код должен также корректно выполняться и в среде ОС контроллера Аккорд. Таким образом, дополнительно необходимо выполнять ручное тестирование.

На основании вышесказанного можно сделать вывод, что в случае с программно-аппаратными СЗИ, функционирующими до старта ОС, (на примере «Аккорд-АМДЗ») можно использовать либо только полуавтоматизированное тестирование без внесения каких-либо доработок в конструктив самого СЗИ, либо автоматизированное тестирование, для которого потребуется изменять как программную так и аппаратную компоненту СЗИ. Однако в обоих случаях потребуется дополнительно проводить проверки как минимум работоспособности СЗИ на различных СВТ.

Программно-аппаратные СЗИ, функционирующие в ОС

Рассмотрим СЗИ, функционирующие в ОС, в конструктив которых входит флеш-память (далее – СЗИ с флеш-памятью). Такие СЗИ представляют собой комплекс программного обеспечения и составного аппаратного устройства (как правило, отчуждаемого), включающего в себя:

• компоненты, непосредственно реализующие функции по защите информации (микропроцессор, внутреннее ПО, ПО в ОС и т.п.);
• прочие компоненты, не реализующие функции защиты напрямую, в данном случае – флеш-память.

Например, к средствам защиты с флеш-памятью можно отнести ПСКЗИ ШИПКА на базе ШИПКА-2.0 и служебные носители (СН) Секрет. При тестировании таких СЗИ (как ручном, так и автоматизированном) необходимо дополнительно к привычным методам тестирования ПО провести такие проверки, как:

1. тестирование флеш-памяти (определение скоростных характеристик, нагрузочные тесты и т.п.);
2. тестирование взаимодействия компонент, реализующих защитные функции, с флеш-памятью.

Таким образом, при тестировании СЗИ, функционирующих в ОС, в конструктив которых входит флеш-память, необходимо дополнить ПМИ приведенными выше проверками. При этом следует отметить, что, например, тестирование флеш-памяти в аспекте определения её надежности провести вручную можно, но, как минимум, неразумно по временным затратам, так как это требует выполнения большого количества циклов атомарных операций чтения/записи различных по объему блоков данных. Для тестирования флеш-памяти целесообразно применять существующие и широкодоступные специализированные средства, вместо разработки собственных тестов [4].

При рассмотрении возможности автоматизации тестирования программно-аппаратных СЗИ с флеш-памятью, возникает нюанс, связанный с необходимостью переподключения аппаратной составляющей в процессе тестирования функционала продукта, используемого конечными пользователями. Для решения такой проблемы необходимо использовать специальные USB-прерыватели, позволяющие выполнять отключение питания на шине USB (для самого СЗИ), без физического отключения устройства. То есть применение такого прерывателя позволяет полноценно эмулировать работу реального пользователя программно-аппаратного СЗИ.

В соответствии с вышесказанным автоматизация тестирования СЗИ с флеш-памятью, в общем случае возможна, но требует выполнения ряда условий, таких как:

Условие 2.1. Применение USB-прерывателя в случае необходимости переподключения СЗИ в ходе настройки или использования.

Условие 2.2. Поддержка среды функционирования скриптов автоматизации в целевой ОС.

Условие 2.3. Наличие скриптов автоматизации или прочих средств тестирования флеш-памяти и взаимодействия компонент программно-аппаратных СЗИ.

Ручное же тестирование таких СЗИ достаточно затруднено и требует, как минимум, использования сторонних программ для тестирования флеш-памяти (т.е. желательна, как минимум, частичная автоматизация).

Формализация критериев применимости методов тестирования ПО к программно-аппаратным СЗИ

Обозначим как M = {m₁, m₂, m₃, m₄,...} - множество всех программно-аппаратных СЗИ, где m₁, m₂, m₃, m_{4, ...} - некоторые программно-аппаратные СЗИ (например, средства защиты, рассмотренные выше – ШИПКА и Аккорд-АМДЗ).

Обозначим М_р – множество программно-аппаратных СЗИ, для которых возможно ручное тестирование.

М = М_р для любого непротиворечивого СЗИ (М_р ⊆ М по определению, то есть все программно-аппаратные СЗИ могут быть проверены вручную).

В соответствии с этим множество М можно представить в следующем виде:

М_а U М_па ⊆ M = M_р, где:

М_а – множество программно-аппаратных СЗИ, тестирование которых можно проводить автоматизировано;

М_па – множество программно-аппаратных СЗИ, тестирование которых возможно автоматизировать только частично.

При этом:

1. М_а ⊆ М_р = M, М_па ⊆ М_р = M – подмножества множества М.
2. Подмножества М_а и М_па не пересекаются - М_а ∩ М_па = ∅.

Множество программно-аппаратных СЗИ (M) представлено на рис. 1.

Рисунок 1: Множество программно-аппаратных СЗИ (М)

Также множество М может быть представлено следующим образом:

M = P_ос U P_доос, где:

P_ос – множество программно-аппаратных СЗИ, функционирующих в среде ОС;

P_доос – множество программно-аппаратных СЗИ, функционирующих до старта ОС.

Множество Р_ос состоит из двух подмножеств: Р_ос = Р_usb U P_др, где:

P_usb – множество программно-аппаратных СЗИ, функционирующих в среде ОC, аппаратная часть которых подключается в USB-порт СВТ;

P_др – множество других программно-аппаратных СЗИ, функционирующих в среде ОС, не входящих в P_usb.

При этом Р_usb ∩ P_др = ∅.

Определение 1:

Определим математическую модель некоторого абстрактного программно-аппаратного СЗИ следующим образом: ∀ m ∈ M может быть представлено в виде m = ∑(F, V, OP) - набора следующих множеств:

• F - множество целевых функций, которые выполняет программно-аппаратное СЗИ (например: шифрование, подпись, контроль доступа и т.п.);
• V - множество состояний, в которых может находиться аппаратная компонента (при этом v₀ ∈ V - начальное состояние, например, когда аппаратная составляющая не инициализирована);
• OP - множество функций переходов программно-аппаратного СЗИ из одного состояния в другое (например, инициализация аппаратной компоненты и ее переход в инициализированное состояние).

В каждый момент времени СЗИ может находиться в определенном состоянии (F`, v, OP), где v ∈ V – текущее состояние m, F` - множество выполнимых в данном состоянии v целевых функций m. При этом объединение U F` = F, ∀ v ∈ V.

В общем случае ∀ F` ⊆ F, F`(input) =	True (если F` выполнена успешно)
	False (если произошла ошибка)

где:

input – набор формальных параметров функции F`, зависит от реализации функции (например, для шифрования файла – это файл, который нужно зашифровать, куда сохранить зашифрованный результат, и ключ шифрования).

op ∈ OP: (F`, v<sub>1</sub>, OP) → (F``, v<sub>2</sub>, OP), то есть m переходит из одного состояния (F`, v₁, OP) в другое (F``, v₂, OP).

При этом из-за особенностей конкретных программно-аппаратных СЗИ некоторые функции, которые выполняет СЗИ, могут быть выполнены только в определенных состояниях, в которых находится аппаратная компонента СЗИ. Например, как правило, нельзя выполнять никакой функционал СЗИ до того, как выполнится первоначальная инициализация его аппаратной компоненты, нельзя использовать функции шифрования криптографического СЗИ, если не сгенерированы ключи шифрования и т.п.

Таким образом, Определение 1 подразумевает, что некоторые функции из множества F могут быть вычислимы в понятиях теории алгоритмов [5] только в определенных состояниях из множества V, в других состояниях данные функции могут быть невычислимы.

Также функции из множества OP могут быть как функциями, реализованными непосредственно в самом программно-аппаратном СЗИ (нецелевые функции, например, функция инициализации устройства), так и функциями, внешними по отношению к нему, которые необходимо реализовывать дополнительно (например, ввод пин-кода, переподключение аппаратной компоненты и т.д.)

Определим множество функций ручных проверок для программно-аппаратных СЗИ.

Определение 2:

Пусть m ∈ M и m = ∑(F, V, OP) в соответствии с Определением 1. Пусть F = {F₁, ..., F_n}, где n ∈ N - конечное множество целевых функций, которые выполняет m.

Так как M = М_р, то для m существует R = R₁ U … U R_n, где n ∈ N – конечное множество функций ручных проверок, соответствующих функциям F = {F₁, ..., F_n}.

При этом если представить все функции в F в виде набора выполняющихся друг за другом подфункций f (шагов, необходимых для выполнения самой функции):

∀ Fi ⊆ F (i = 1,…, n), Fi(input) =	f1(input1)
	…
	fk (inputk)

При этом ∀ fj ⊆ Fi (j = 1,…, k), fj(inputj) =	True (если fj выполнена успешно) False (если произошла ошибка)
Если fj = False, то Fi = False; Если fj = True, то Fi = True, если j = k

то в таком случае можно определить функции ручных проверок следующим образом:

В общем случае ∀ Ri ⊆ R, Ri (input, output) = где i = 1,...,n.	True (если Fi выполнена успешно)
	False (если произошла ошибка)
∀ rj ∈ Ri, rj(inputj, outputj) = где j = 1,...,k.	True (если fj выполнена успешно).
	False (если произошла ошибка)
где: outputj – набор выходных данных (лог работы, код ошибки, дополнительный результат и т.д.). output = outputj, если rj = False (Ri = False). output = outputj+1, если rj = True, j ≠ k (Ri = True, output = outputj, если j = k).

Определение 2.1:

∀ r_j ∈ R_i вычислима, если соответствующая ей f_j ∈ F_i вычислима, для ∀ j = 1,…,k.

Определение 2.2:

Пусть m = ∑(F, V, OP) ∈ M. Тогда m ∈ M_р, если ∀ R_i ⊆ R (множество функций ручных проверок по Определению 2), R_i – множество вычислимых функций, i = 1,…, n.

Основываясь на Определениях 1, 2, 2.1 и 2.2 формализуем общий критерий возможности проведения ручного тестирования программно-аппаратных СЗИ.

Утверждение 1 (Общий критерий возможности проведения ручного тестирования программно-аппаратных СЗИ):

Если m = ∑(F, V, OP) ∈ M, в состоянии v₀ ∈ V, то m ∈ M_p ⇐⇒:

1. либо ∀ r_j ∈ R_i вычислимы в состоянии v₀ ∈ V для ∀ R_i ⊆ R;
2. либо ∃ op₁,…, op_L ∈ OP (функции перехода в состояния v₁,…, v_L): ∀ r_j ∈ R_i, невычислимые в состоянии v₀, вычислимы в одном из состояний v₁,…, v_L, для ∀ R_i ⊆ R.

То есть Ri (input, output) =	r1(input1, output1) … opl
	rj(inputj, outputj)
	…
	rk(inputk, outputk)

где op_l – функция перехода в состояние, где r_j(input_j, output_j) – вычислима.

Определим множество функций (скриптов) автоматизации для программно-аппаратных СЗИ.

Определение 3:

Пусть m ∈ M и m = ∑(F, V, OP) в соответствии с Определением 1. Пусть F = {F₁, ..., F_n}, где n ∈ N - конечное множество целевых функций, которые выполняет m.

Для m определим множество функций (скриптов) автоматизации, применимых как для ПО, так и для программно-аппаратных СЗИ, как S = S₁ U … U S_n, где n ∈ N – конечное множество функций автоматизированных проверок, соответствующих целевым функциям F = {F₁, ..., F_n}.

При этом если представить все функции в F в виде набора выполняющихся друг за другом подфункций f (аналогично Определению 2), то в таком случае можно определить функции автоматизированных проверок следующим образом:

∀ Si ⊆ S, Si (input, output, count) = где i = 1,...,n.	True (если Fi выполнена успешно)
	False (если произошла ошибка)
count – количество повторов выполнения автоматизированного скрипта.
Si (input, output, count) =	for (i = 0,…, count) { s1(input1, output1) … sk(inputk, outputk) }
∀ sj ∈ Si, sj(inputj, outputj) = где j = 1,...,k.	True (если fj выполнена успешно) False (если произошла ошибка)
где outputj – набор выходных данных (лог работы, код ошибки, дополнительный результат и т.д.), необходимый для анализа и отчетности средства автоматизации.
оutput =	{ output`1 … output`count }

где:

output`_l = output_j, l = 1,…,count, если s_j = False на итерации l.

output`<sub>l</sub> = output<sub>j+1</sub>, l = 1,…,count, если s<sub>j</sub> = True, j≠k на итерации l (output` _l = output_j, если j = k).

Определение 3.1:

∀ s_j ∈ S_i вычислимая функция автоматизации, если соответствующая ей f_j ∈ F_i вычислима, для ∀ j = 1,…,k и существуют достаточные условия для выполнения s_j и возможность фиксации результата s_j.

Определение 3.2:

Пусть m = ∑(F, V, OP) ∈ M. Тогда m ∈ M_а, если ∀ S_i ⊆ S (множество функций автоматизации по Определению 3), S_i – множество вычислимых функций автоматизации, i = 1,…, n.

Основываясь на Определениях 1, 3, 3.1 и 3.2 формализуем общие критерии возможности полной и частичной автоматизации тестирования программно-аппаратных СЗИ.

Утверждение 2 (Общий критерий возможности автоматизации тестирования программно-аппаратных СЗИ):

Если m = ∑(F, V, OP) ∈ M, в состоянии v₀ ∈ V, то m ∈ M_а ⇐⇒:

1. либо ∀ s_j ∈ S_i является вычислимой функцией автоматизации в состоянии v₀ ∈ V, для ∀ S_i ⊆ S;
2. либо ∃ op₁,…, op_L ∈ OP (автоматизированные функции перехода в состояния v₁,…, v_L): ∀ s_j ∈ S_i, невычислимые функции автоматизации в состоянии v₀, являются вычислимыми функциями автоматизации в одном из состояний v₁,…, v_L, для ∀ S_i ⊆ S.

То есть Si (input, output, count) =	for (i = 0,…, count) {
	s1(input1, output1)
	… opl sj(inputj, outputj) …
	sk(inputk, outputk) }

где op_l – функция перехода в состояние, где s_j(input_j, output_j) – вычислима.

Следствие (Общий критерий возможности частичной автоматизации тестирования программно-аппаратных СЗИ):

Если m = ∑(F, V, OP) ∈ M, в состоянии v₀ ∈ V, то m ∈ M_па ⇐⇒ ∃ S_i ⊆ S, S_i – множество вычислимых функций автоматизации, i = 1,…, n ⇐⇒:

1. либо ∀ s_j ∈ S_i является вычислимой функцией автоматизации в состоянии v₀ ∈ V, для S_i ⊆ S;
2. либо ∃ op₁,…, op_L ∈ OP (автоматизированные функции перехода в состояния v₁,…, v_L): ∀ s_j ∈ S_i невычислимые функции автоматизации в состоянии v₀, являются вычислимыми функциями автоматизации в одном из состояний v₁,…, v_L, для S_i ⊆ S.

Применим общий критерий возможности проведения ручного тестирования из Утверждения 1 к таким программно-аппаратным СЗИ, как «Аккорд-АМДЗ» и ПСКЗИ ШИПКА.

Обозначим СЗИ НСД «Аккорд-АМДЗ» как m_амдз, ПСКЗИ ШИПКА как m_шипка (m_амдз, m_шипка ∈ M).

Аксиома 1: m_амдз ∈ P_доос.

Аксиома 2: m_шипка ∈ P_usb ⊆ P_ос.

Утверждение 3: Пусть m_амдз = ∑(F_амдз, V_амдз, OP_амдз) ∈ M – СЗИ НСД «Аккорд-АМДЗ», а m_шипка = ∑(F_шипка, V_шипка, OP_шипка) ∈ M – ПСКЗИ ШИПКА.

Тогда m_амдз = ∑(F_амдз, V_амдз, OP_амдз) ∈ M_р, m_шипка = ∑(F_шипка, V_шипка, OP_шипка) ∈ M_р.

Докажем Утверждение 3 для «Аккорд-АМДЗ» и ПСКЗИ ШИПКА.

«Аккорд-АМДЗ»

m_амдз может находиться в следующих состояниях v₀ , v₁ , v₂ , v₃ ∈ V_амдз:

v₀ – начальное состояние, когда контроллер неинициализирован (пустая БД пользователей, необходимо создать гл.Администратора);

v₁ – состояние, когда контроллер готов к работе (инициализирован, зарегистрирован гл. Администратор, могут быть созданы пользователи и списки КЦ);

v₂ – состояние, когда контроллер завершил работу (проведена и/а, проведены контрольные процедуры, результаты переданы в ОС);

v₃ – состояние, когда контроллер находится в технологическом режиме.

Из принципа работы «Аккорд-АМДЗ» следует, что все его целевые функции вычислимы либо в состоянии v₁ , либо в состоянии v₂.

В начальный момент времени работы контроллера он не может находиться в состоянии v₂, при этом он может находится в одном из состояний - v₀, v₁, v₃. Поэтому, по Утверждению 1, чтобы сделать вычислимой задачу ручного тестирования «Аккорд-АМДЗ» должны существовать функции перехода op₁,…, op₅ ∈ OP из одних состояний m_амдз в другие:

• op₁: v₀ → v₁;
• op₂: v₁ → v₂;
• op₃: v₀ → v₂;
• op₄: v₃ → v₁;
• op₅: v₃ → v₂.

Возможные состояния и функции переходов m_амдз изображены на рис. 2.

Рисунок 2: Возможные состояния и функции переходов m_амдз

Для m_амдз такими функциями перехода являются его штатные возможности, а именно:

op₁ – функция инициализации контроллера (инициализация БД пользователей, регистрация гл. Администратора);

op₂ – функция перехода при успешном прохождении процедуры и/а пользователя и контроля целостности (в случае неуспешной и/а пользователя или непрохождения КЦ контроллер переходит в состояние v₁);

op₃ – составная функция перехода, состоящая из op₁ и op₂;

op₄ – перевод контроллера из технологического режима в рабочий (ручная установка или снятие перемычки и т.п.);

op₄ – составная функция перехода, состоящая из op₄ и op₂.

Все перечисленные функции переходов могут быть выполнены вручную, в соответствии с чем все целевые функции могут быть вычислимы после выполнения соответствующих переходов при ручном тестировании «Аккорд-АМДЗ», то есть m_амдз ∈ M_р, что и требовалось доказать.

ПСКЗИ ШИПКА

m_шипка может находиться в следующих состояниях v₀ , v₁ , v₂ , v₃ , v₄ ∈ V_шипка:

v₀ – начальное состояние, когда устройство неинициализировано (не форматировано, не заданы параметры авторизации, пароль администратора, PIN и PUK-код пользователя);

v₁ – состояние, когда устройство инициализировано и подготовлено к работе (отформатировано, заданы параметры авторизации, пароль администратора, PIN и PUK-код пользователя);

v₂ – состояние, когда устройство готово к работе и не введен PIN-код пользователя (сгенерированы или импортированы криптографические ключи и сертификаты, необходимые для выполнения процедур шифрования и подписи, или зарегистрирован пользователь для осуществления защищенного входа в ОС, или созданы пасскарты, или существует одновременное сочетание двух или более перечисленных пунктов);

v₃ – состояние, когда устройство готово к работе аналогично v₂, но при этом введен корректный PIN-код пользователя.

v₄ – состояние, когда устройство находится в технологическом режиме.

В начальный момент времени работы ПСКЗИ ШИПКА может находиться в состояниях v₀, v₁, v₂, v₄ и не может находится в состоянии v₃.

При этом, так как ПСКЗИ ШИПКА является отчуждаемым устройством (m_шипка ∈ P_usb), то для m_шипка существуют состояния v`<sub>0</sub> , v`₁ , v`<sub>2</sub> , v`₄ ∈ V_шипка аналогичные состояниям v₀ , v₁ , v₂ , v₄ ∈ V_шипка, но в которых устройство не подключено в USB-порт СВТ. В начальный момент времени работы ПСКЗИ ШИПКА также может находиться в состояниях v`<sub>0</sub>, v`₁, v`<sub>2</sub>, v`₄.

Из принципа работы ПСКЗИ ШИПКА следует, что все его целевые функции вычислимы только в состоянии v₃.

Поэтому, по Утверждению 1, чтобы сделать вычислимой задачу ручного тестирования для ПСКЗИ ШИПКА должны существовать функции перехода op₁,…, op₅ ∈ OP из одних состояний m_шипка в другие:

• op₁: v₂ → v₃;
• op₂: v`<sub>2</sub> → v<sub>3</sub>;
• op<sub>3</sub>: v<sub>1</sub> → v<sub>3</sub>;
• op<sub>4</sub>: v`₁ → v₃;
• op₅: v₀ → v₃;
• op₆: v`<sub>0</sub> → v<sub>3</sub>;
• op<sub>7</sub>: v<sub>4</sub> → v<sub>3</sub>;
• op<sub>8</sub>: v`₄ → v₃.

Возможные состояния и функции переходов m_шипка изображены на рис. 3.

Рисунок 3: Возможные состояния и функции переходов m_шипка

Для m_шипка такими функциями перехода являются:

op₁ – ввод PIN-кода;

op₂ – составная функция перехода, состоящая из подключения устройства в USB-порт СВТ и выполнения op₁;

op₃ – составная функция перехода, состоящая из процедур генерации или импорта криптографических ключей и сертификатов, или регистрации пользователя для осуществления защищенного входа в ОС, или создания пасскарты, или одновременное сочетание двух или более перечисленных пунктов, а также из выполнения op₁;

op₄ – составная функция перехода, состоящая из подключения устройства в USB-порт СВТ и выполнения op₃;

op₅ – составная функция перехода, состоящая из инициализации устройства и выполнения op₃;

op₆ – составная функция перехода, состоящая из подключения устройства в USB-порт СВТ и выполнения op₅;

op₇ – составная функция перехода, состоящая из перевода устройства из технологического режима в состояние v₀ , v₁ , или v₂ и выполнения op₅, op₃ или op₁ соответственно;

op₈ – составная функция перехода, состоящая из подключения устройства в USB-порт СВТ и выполнения op₇;

Все перечисленные функции переходов могут быть выполнены вручную, в соответствии с чем все целевые функции могут быть вычислимы после выполнения соответствующих переходов при ручном тестировании ПСКЗИ ШИПКА, что и требовалось доказать.

Формализуем частные критерии возможности автоматизации тестирования «Аккорд-АМДЗ» и ПСКЗИ ШИПКА, используя Условия 1.1-1.3 и Условия 2.1-2.3 соответственно и общий критерий из Утверждения 2.

Утверждение 4 (частный критерий возможности автоматизации тестирования «Аккорд-АМДЗ»):

Пусть m_амдз = ∑(F_амдз, V_амдз, OP_амдз) ∈ M – СЗИ НСД «Аккорд-АМДЗ».

Тогда m_амдз = ∑(F_амдз, V_амдз, OP_амдз) ∈ M_а ⇐⇒ ∀ S_i ⊆ S (определенных в соответствии с Определением 3) выполняются следующие условия:

1. ∀ s_j ∈ S_i являются вычислимыми функциями автоматизации в каком-либо состоянии v ∈ V_амдз.
2. ∃ op₄ ∈ OP, позволяющая автоматизировано переходить из состояния v₃ (технологический режим) в состояние v₁ (рабочий режим), в следствии чего невычислимые в состоянии v₃ функции автоматизации s_j ∈ S_i становятся вычислимыми функциями автоматизации в состоянии v₁ или v₂.

Из Определения 3, 3.1, 3.2 и Утверждения 3 следует, что ∀ s_j ∈ S_i должны быть вычислимыми функциями автоматизации в каком-либо состоянии v ∈ V_амдз.

Из Утверждения 3 следует, что все функции переходов из OP_амдз, кроме op_4, могут быть автоматизированы, в соответствии с чем, если каким-либо образом автоматизировать op₄, то для вычислимости задачи автоматизированного тестирования «Аккорд-АМДЗ» достаточно будет вызывать функции автоматизированного перехода из одного состояния (в котором некоторая s_j невычислима) в другое (в котором эта функция s_j вычислима).

Утверждение 5 (частный критерий возможности автоматизации тестирования ПСКЗИ ШИПКА):

Пусть m_шипка = ∑(F_шипка, V_шипка, OP_шипка) ∈ M – ПСКЗИ ШИПКА.

Тогда m_шипка = ∑(F_шипка, V_шипка, OP_шипка) ∈ M_а ⇐⇒ ∀ S_i ⊆ S (определенных в соответствии с Определением 3) выполняются следующие условия:

1. ∀ s_j ∈ S_i являются вычислимыми функциями автоматизации в каком-либо состоянии v ∈ V_шипка.
2. ∃ op₂, op₄, op₆, op₈ ∈ OP, позволяющие автоматизировано подключать/переподключать устройство в USB-порт СВТ (с дополнительными дальнейшими действиями), вследствии чего невычислимые функции автоматизации s_j ∈ S_i становятся вычислимыми.

Доказательство аналогично Утверждению 4. В качестве указанных в условиях op₂, op₄, op₆, op₈ ∈ OP может выступать USB-прерыватель, способный подавать или прерывать питание на USB-порт СВТ. Поэтому для вычислимости задачи автоматизированного тестирования ПСКЗИ ШИПКА достаточно включать и выключать USB-прерыватель до или после определенных функций автоматизации.

Таким образом, можно сделать вывод, что и для программно-аппаратных СЗИ, функционирующих до момента страта ОС и для программно-аппаратных СЗИ, функционирующих в ОС применимы все те же методы тестирования программного обеспечения, но с учетом некоторых особенностей, индивидуальных для каждого СЗИ. Для того чтобы выполнять автоматизированное тестирование рассмотренных программно-аппаратных СЗИ, необходимо обязательное выполнение описанных выше критериев.

Литература

1. Тамре Л. Введение в тестирование программного обеспечения // Вильямс. 2003. Стр. 368.
2. Котляров В.П. Основы тестирование программного обеспечения // Интернет-Университет Информационных Технологий. БИНОМ. Лаборатория знаний, М., 2006. Стр. 285
3. Борисова Т. М., Кузнецов А. В. Проблемы тестирования СЗИ, функционирующих до старта ОС // Комплексная защита информации. Электроника инфо. Материалы XVIII Международной конференции 21–24 мая 2013 года, Брест (Республика Беларусь). 2013. С. 114-115
4. Борисова Т. М., Обломова А. И. Способы автоматизации тестирования СЗИ, функционирующих в ОС, на примере ПСКЗИ ШИПКА // Комплексная защита информации. Электроника инфо. Материалы Электроника инфо. Материалы XVIII Международной конференции 21–24 мая 2013 года, Брест (Республика Беларусь). 2013. С. 117-118
5. Мальцев А.Н. Алгоритмы и рекурсивные функции. – М., Наука, 1986. – 366 с.

Автор: Каннер(Борисова) Т. М.

Дата публикации: 01.01.2015

Библиографическая ссылка: Каннер (Борисова) Т. М. Применимость методов тестирования ПО к программно-аппаратным СЗИ // Вопросы защиты информации: Научно-практический журнал. М.: ФГУП «ВИМИ», 2015. Вып. 1. С. 30–39.

---