Тестирование средств защиты информации

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

Ключевые слова: СЗИ НСД, тестирование, загрузка ОС, аппаратный модуль доверенной загрузки, флеш-память

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

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

Особенность тестирования СЗИ, в конструктив которых входит флеш-память

К аппаратным составляющим СЗИ, требующим универсального тестирования, относится флеш-память с доступом как Mass Storage (далее флеш-память). Примерами СЗИ с такой флеш-памятью являются ПСКЗИ ШИПКА на базе ШИПКА-2.0, которое может использоваться и как самостоятельное СКЗИ, так и в составе ПАК «Центр-Т», и служебные носители (СН) Секрет из ПАК «Личный Секрет», «Секрет Фирмы», «Секрет Особого Назначения».

ШИПКА-2.0 состоит из микропроцессора, в котором аппаратно реализованы все современные российские криптографические алгоритмы, и флеш-памяти, в которой можно хранить различные данные. Флеш-память ШИПКи-2.0 в ПАК «Центр-Т» используется для хранения образов начальной загрузки и для загрузки образов ПО ТС по сети для получения доступа к терминальному серверу.

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

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

Существует два направления тестировании флеш-памяти: тестирование скорости чтения/записи и нагрузочное тестирование. Оба эти подвида тестирования должны использоваться для тестирования флеш-памяти рассмотренных выше СЗИ.

Тестирование скорости флеш-дисков состоит из изменения и анализа следующих параметров:

• время доступа при чтении и записи с использованием фиксированных тестовых блоков 4, 64 и 1024 Кбайт;
• скорость записи и чтения одного большого файла объемом несколько Гб;
• скорость записи и чтения пакета мелких файлов размером от нескольких байтов до 500 КВ, представляющих собой, например, сохраненные html-странички, небольшие PDF-документы, материалы в форматах .doc и .xls.

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

Нагрузочные тесты подразделяются на:

• тестирование на физическом уровне (со всей доступной областью памяти). Результатом такого тестирования является показатель общей устойчивости памяти к частоте записи на нее произвольной информации (реальное количество возможных циклов перезаписи информации без нарушения нормального функционирования памяти). В данном тестировании проводится проверка именно равномерной записи данных на носитель.
• тестирование на уровне абстракции файловой системы (с разделами, логическими дисками, партициями). Результатом такого тестирования является показатель рабочей устойчивости памяти к частоте записи на нее произвольной информации — т.е. будет учитываться частая запись в наиболее активные области раздела.

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

Для проведения всех перечисленных видов тестирования СЗИ может использоваться ряд утилит, широкодоступных в настоящее время для тестирования устройств хранения информации (HDD, CD-ROM, Flash-drive, floppy и т.д.). Примером таких утилит, находящихся в бесплатном доступе, могут служить утилиты HD_Speed и CheckFlash.

Утилита HD_Speed предназначена для тестирования скорости чтения/записи устройств для хранения информации. В этой утилите можно задать смещение и размер считываемого/записываемого блока, выбор этих параметров может повлиять на скорость работы. Помимо этого можно выбрать отдельный логический раздел на жестком диске и проверить, как, например, влияет файловая система или наличие «плохих» кластеров на производительность.

Check Flash — утилита, предназначенная для проверки работоспособности флеш-накопителей, а также позволяющая при помощи тестов определить мгновенную и среднюю скорость чтения/записи. В этой утилите можно проверить стабильность чтения/записи с носителя и на него как на логическом уровне, так и на физическом.

При использовании обеих утилит можно определить количество ошибок чтения/записи, возникших в процессе тестирования, а вся полученная информация может сохраняться в журнал для дальнейшего анализа и сравнения результатов.

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

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

Проблемы тестирования СЗИ, функционирующих до старта ОС

Программно-аппаратные СЗИ можно разделить на две группы:

• СЗИ, функционирующие до момента загрузки операционной системы (ОС);
• СЗИ, функционирующие в ОС.

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

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

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

• идентификация/аутентификация пользователя;
• проверка целостности технических и программных средств ПК (с использованием механизма пошагового контроля целостности);

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

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

• ручное тестирование — все действия выполняются тестировщиком;
• автоматизированное тестирование — для выполнения тестирования применяются специализированные сторонние программные средства;
• полуавтомтизированное тестирование — часть проверок выполняется специализированными сторонними программными средствами, а часть — вручную.

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

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

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

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

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

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

Способы автоматизации тестирования СЗИ, функционирующих в ОС, на примере ПСКЗИ ШИПКА

Согласно общепринятой классификации выделяют несколько основных видов тестирования ПО:

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

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

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

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

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

Рассмотрим преимущества автоматизированного тестирования по сравнению с ручным тестированием:

• повторяемость — все написанные тесты всегда будут выполняться однообразно, то есть исключен «человеческий фактор», «компьютер» не пропустит тест по неосторожности и ничего не напутает в результатах;
• быстрое выполнение — автоматизированному тесту не нужно «сверяться» с инструкциями и документациями, это сильно экономит время проверки;
• меньшие затраты времени на анализ результатов тестирования и адаптацию тестов в случае изменения функционала — анализ результатов тестирования автоматических тестов при изменении какого-либо функционала продукта, их адаптация и повторное проведение тестирования требует, как правило, меньшее время, чем аналогичные действия того же объема тестирования вручную;
• автоматическое формирование и рассылка отчетов — автоматизированные тесты могут автоматически рассылать и сохранять отчеты о результатах тестирования;
• выполнение без вмешательства человека — во время выполнения тестов тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время.

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

Функциональное тестирование СЗИ, выполняемое вручную, проводится по заранее разработанной тестировщиком программе и методике тестирования (ПМИ). При автоматизированном функциональном тестировании СЗИ, как правило, используются скрипты (тесты, разработанные при помощи специальных программ) для эмуляции действий пользователя. Существует множество программ, позволяющих разрабатывать подобные скрипты. Одни из них основываются на технологии поиска и автоматизации работы с элементами графического интерфейса на основе изображений (скриншотов), другие на основе ключевых слов и т.д. Главным плюсом использования скриптов является экономия времени на тестировании монотонных и однотипных действий, например, при переборе входных данных. Таким образом, один раз написанный тест может долго служить, экономя время тестировщика. Но это будет так до первого изменения в поведении тестируемого СЗИ. Если СЗИ начинает функционировать по-другому, даже если это незначительные отклонения (например, выводится новое информационное окно или была изменена цветовая гамма), то требуется вносить изменения в скрипт теста. Это одна из проблем при использовании такого вида автоматизации — будет ли сэкономленное время перевешивать время написания\изменения скриптов. И конечно, нужно учитывать, что автоматизировать тестирование дружественности интерфейса невозможно.

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

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

Первый способ, это классический способ уже рассмотренный выше — использование автоматизированных скриптов, разработанных при помощи специальных программ автоматизации. Эти скрипты позволят проводить и функциональное и нефункциональное тестирование ПСКЗИ ШИПКА. Однако, поскольку ПСКЗИ ШИПКА состоит из программного и аппаратного компонента, это обязательно нужно учитывать при организации тестирования — в ходе функционального тестирования ПСКЗИ ШИПКА аппаратную часть продукта необходимо переподключать к USB-порту ПК, что нарушает идеологию проведения автоматизированных тестов, которые должны проводится без участия «человека». Поэтому полностью автоматизировать такое функциональное тестирование затруднительно, так как в данном случае необходимо участие тестировщика для выполнения указанных действий. Аналогичная проблема возникает при нефункциональном тестировании — в случае возникновения ошибок в ходе выполнения скрипта устройство необходимо физически переподключить к ПК.

Второй способ автоматизации тестирования ПСКЗИ ШИПКА представляет собой использование комплекта разработчика (SDK — Software Development Kit) для стандартных интерфейсов, который реализован для ПСКЗИ ШИПКА в целях возможности использования криптографической функциональности устройства сторонними разработчиками в своих продуктах. В настоящее время для ПСКЗИ ШИПКА реализовано три стандартных интерфейса: Crypto API, PKCS#11, APDU, а SDK для них включает набор примеров по их использованию. Эти примеры можно использовать для автоматизации функционального тестирования ПСКЗИ ШИПКА, так как их успешное прохождение, гарантирует, конечно, не полностью, но частично, что и те утилиты, которые работают на базе этих интерфейсов, будут работать корректно с ШИПКой. Естественно, при этом остается необходимость функционального и нефункционального тестирования самих утилит продукта.

На основании описанного можно сделать вывод, что ручное и автоматизированное тестирование — две неотъемлемые части при проверке качества любого выпускаемого продукта, в том числе и СЗИ. Невозможно полностью автоматизировать все тесты. Также автоматизированный тест никогда не сможет проверить «дружественность» интерфейса и т.д. Но однозначно нужно признать, что внедрение автоматизированного тестирования значительно сокращает время на проведение проверок, и с помощью него становится возможным провести тестирование, которое человек сможет выполнить только за достаточно большой период времени, а, возможно, и никогда не сможет. А именно, сложно представить, как тестировщик вручную тестирует предельные значения, например, в случае с ПСКЗИ ШИПКА, проверяет корректность функционирования устройства с максимально возможным количеством криптографических ключей в устройстве, которое может быть больше 200. Для этого тестировщику нужно вручную сгенерировать все эти ключи и только потом проверить корректность функционирования устройства. Если же окажется, что в этом процессе возникнут ошибки, то нужно будет поэтапно уменьшать количество ключей и повторять тестирование до определения критического значения. Также тестировщику сложно вручную проводить стрессовое тестирование, при котором он должен генерировать различные случайные значения и подавать их в качестве входных параметров в устройство, для проверки реакции ПСКЗИ ШИПКА на каждое из них. В случае, с ПСКЗИ ШИПКА например, необходимо задавать различные случайные значения длины PIN-кода и проверять, как устройство будет реагировать на каждое из введенных значений. Эти факты подтверждают правильность подхода использования автоматизированного тестирования наряду с ручным тестированием.

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

Авторы: Каннер(Борисова) Т. М.; Кузнецов А. В.; Обломова А. И.

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

Библиографическая ссылка: Каннер (Борисова) Т. М., Кузнецов А. В., Обломова А. И. Тестирование средств защиты информации // Информационная безопасность. Материалы XIII Международной конференции. Таганрог 2013. Часть. 1. С. 121–129.

---