Способ автоматизированного тестирования программно-аппаратных систем и комплексов

Изобретение относится к области вычислительной техники. Технический результат заключается в обеспечении обнаружения уязвимых программных и аппаратных средств в процессе автоматизированного тестирования системы программных и аппаратных средств. Технический результат достигается за счет способа тестирования системы программных и аппаратных средств системой автоматизированного проектирования, в котором модули системы автоматизированного проектирования: получают формализованное описание архитектуры тестируемой системы и строят модель использования включающую: вид использования системы, элемент системы, способ реализации данного вида использования; получают из базы угроз формализованное описание известных угроз для систем, сходных с тестируемой и строят модель угроз того же вида, что и модель использования включающая: вид угрозы, элемент системы, способ реализации угрозы, вектор воздействия на систему; сравнивают модель угроз с моделью использования; обнаруживают средства тестируемой системы, которые уязвимы: к виду несанкционированного использования системы, к способу реализации угрозы, к вектору воздействия на систему. 14 з.п. ф-лы, 9 ил.

 

Область техники

Изобретение относится к способам автоматизированного тестирования программно-аппаратных систем и комплексов.

Уровень техники

При проектировании программно-аппаратных систем и комплексов в их архитектуру закладывается достижение одной или нескольких поставленных целей¹ (¹ ГОСТ Р ИСО/МЭК 15288-2005. Национальный стандарт Российской Федерации. Информационная технология. Системная инженерия. Процессы жизненного цикла систем). Цели формируют заинтересованные стороны (англ. stakeholder) - это стороны, имеющие интерес (англ. concern) в этой системе. Интересы заинтересованных сторон, согласно ГОСТ Р 57100-2016² (² ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Национальный стандарт Российской Федерации. Системная и программная инженерия. Описание архитектуры), выражены как польза или проблема. Примерами интересов по отношению к системе, в соответствии с упомянутым стандартом, являются: функциональность, выполнимость, применимость, характеристики системы, свойства системы, известные ограничения, структура, поведение, функционирование, использование ресурсов, надежность, функциональная безопасность (англ. safety)³ (³ ГОСТ Р МЭК 61508-2-2012 Функциональная безопасность систем электрических, электронных, программируемых электронных, связанных с безопасностью), целостность хранимых данных (англ. data integrity) гарантированная доступность по запросу (англ. availability) и т.д.

В качестве заинтересованных сторон при проектировании рассматриваются только уполномоченные пользователи (англ. authorised user) или, как их еще называют в упомянутом стандарте, правообладатели, что говорит о том, что заинтересованной стороной являются только пользователи (группы, организации), которым будет разрешено выполнять некоторую операцию в системе для реализации интереса, или чей интерес должен быть учтен по требованию стандарта (например, стандарта, устанавливающего требования функциональной безопасности). В итоге создается система, удовлетворяющая требованиям уполномоченных пользователей и требованиям функциональной безопасности. Для обеспечения же информационной безопасности (англ. security)⁴ (⁴ В том числе безопасность данных (англ. data security), конфиденциальность данных (англ. data confidentiality), безопасность персональных данных (англ. privacy)) созданной системы впоследствии будут использоваться дополнительные средства, которые чаще всего не были предусмотрены архитектурой изначально, и данный факт может существенно отразиться, при их использовании, на реализации интересов уполномоченных пользователей и соблюдении требований функциональной безопасности. Также информационная безопасность может обеспечиваться за счет средств, которые предусмотрены архитектурой, но без учета интересов уполномоченных пользователей и требований функциональной безопасности, что впоследствии также может повлиять при использовании системы на реализацию интересов уполномоченных пользователей и соблюдении требований функциональной безопасности. Например, в публикации US 20140090071 описывается способ автоматической конфигурации функционирующей системы на основании существующих моделей угроз, но не производится оценка влияния каждой новой конфигурации на реализацию интересов уполномоченных пользователей и соблюдение требований функциональной безопасности.

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

Раскрытие изобретения

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

Технический результат настоящего изобретения заключается в обеспечении обнаружения уязвимых программных и аппаратных средств в процессе автоматизированного тестирования системы программных и аппаратных средств, наличие которых препятствуют достижению целей информационной безопасности, при этом тестирование осуществляется с учетом интересов уполномоченных пользователей и требований функциональной безопасности. Технический результат достигается за счет тестирования системы с применением модели угроз⁵ (⁵ Модель угроз содержит актуальные угрозы для проектируемой системы (отражает интересы злоумышленников), следовательно, для достижения целей информационной безопасности эти угрозы не должны быть реализованы.) и сравнения ее с моделью использования⁶ (⁶ Модель использования содержит актуальные возможности санкционированного использования (отражает интересы уполномоченных пользователей и требования функциональной безопасности), следовательно, они должны реализоваться проектируемой системой.), где исходя из результатов сравнения обнаруживают средства тестируемой системы, которые уязвимы:

• к виду несанкционированного использования системы (далее указанный вид несанкционированного использования);

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

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

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

• только интерес нарушителя;

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

• интерес как нарушителя, так и уполномоченного пользователя и, реализуемых сходными способами.

Получив результаты сравнения обнаруживают средства тестируемой системы, которые уязвимы:

• к виду несанкционированного использования системы (далее указанный вид несанкционированного использования);

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

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

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

В частном случае САПР получает на вход формализованное описание архитектуры, которое выполнено в соответствии с ГОСТ Р 57100-2016 и содержит по меньшей мере: элементы системы, в том числе компоненты системы и связи между компонентами; интересы уполномоченных пользователей относительно системы;

В настоящем изобретении сходной может признаваться система, имеющая то же назначение или по меньшей мере один тождественный элемент.

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

В частном случае дополнительно на основании сравнения моделей модуль выбора средств САПР выбирает программные и аппаратные средства для реализации элементов системы, чтобы функциональные возможности или способы конфигурирования таких средств по меньшей мере:

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

• ограничивают указанный способ реализации угрозы;

• ограничивают указанный вектор воздействия на систему.

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

Краткое описание чертежей

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

Фиг. 1 изображает систему автоматизированного проектирования программно-аппаратных систем и комплексов;

Фиг. 2 изображает модель использования и модель угроз для проектируемой системы видеонаблюдения;

Фиг. 3 изображает схему проектируемой системы видеонаблюдения;

Фиг. 4 изображает результаты сравнения модели использования с моделью угроз;

Фиг. 5 изображает результаты сравнения модели использования с моделью угроз, выраженный в виде модели;

Фиг. 6 изображает способ автоматизированного проектирования программно-аппаратных систем и комплексов;

Фиг. 7 изображает вариант реализации проектируемой системы видеонаблюдения;

Фиг. 8 изображает способ автоматизированного тестирования программно-аппаратных систем и комплексов

Фиг. 9 изображает пример компьютерной системы общего назначения, с помощью которой может быть реализовано настоящее изобретение.

Осуществление изобретения

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

Описание архитектуры (англ. architecture description) - рабочий продукт, используемый для выражения архитектуры. Формализуется в частном случае посредством UML (англ. Unified Modeling Language). Согласно ISO/IEC/ IEEE 42010 у описания архитектуры существует много применений со стороны различных заинтересованных сторон по всему жизненному циклу системы, формализованное описание архитектуры применяется в том числе в качестве входов к автоматизированным инструментариям для моделирования, системной имитации и анализа, например САПР.

Архитектура (системы) (англ. architecture) - основные понятия или свойства системы в окружающей среде, воплощенные в ее элементах, отношениях и конкретных принципах ее проекта и развития. Под элементами системы в данном изобретении понимаются, по меньшей мере, компоненты системы и связи между компонентами. Реализованы данные элементы могут быть посредством программных и/или аппаратных средств. Варианты реализации программных и аппаратных средств определяются в процессе проектирования системы.

Интерес (системы) (англ. concern) - польза или проблемы в системе, относящиеся к одной или нескольким заинтересованным сторонам.

Заинтересованная сторона (англ. stakeholder) - индивидуум, команда, организация или их группы, имеющие интерес в системе.

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

Модель использования - формализованное описание вариантов использования системы уполномоченными пользователями. Включает, по меньшей мере:

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

• элемент системы (далее элемент) через который реализуется такое использование;

• способ реализации данного вида использования через указанный элемент;

Нарушитель (англ. unauthorized user) - пользователь, представляющий одну из заинтересованных сторон, который не имеет прав для выполнения некоторой операции в системе для реализации своего интереса.

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

• нарушение конфиденциальности данных;

• нарушение целостности данных/подмена данных;

• нарушение работоспособности системы (в т.ч. отказ в обслуживании);

• неавторизированное вмешательство в функционирование системы;

• и т.д.

Модель угроз - формализованное описание угроз информационной безопасности в отношении системы. Включает, по меньшей мере:

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

• элемент, через который реализуется данный вид угрозы;

• способ реализации угрозы через указанный элемент;

• вектор воздействия на систему для осуществления способа реализации угрозы (вектор атаки);

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

Вектор атаки - направление или конкретный способ воздействия на систему со стороны нарушителя при реализации угрозы безопасности. Признаку «вектор атаки» в рамках данной заявки тождественен признак «вектор воздействия на систему для осуществления способа реализации угрозы». Определяющими вектор атаки характеристиками по меньшей мере могут быть:

• источник или множество источников атаки;

• элемент или множество элементов, являющихся целью атаки;

• вид воздействия;

• средства воздействия.

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

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

Проектирование программно-аппаратных систем и комплексов обеспечивается системой автоматизированного проектирования (далее САПР), вариант реализации которой изображен на Фиг. 1. На вход САПР получает формализованное описание архитектуры проектируемой системы, включающее по меньшей мере: элементы системы, в том числе компоненты системы и связи между компонентами; интересы уполномоченных пользователей относительно системы. На выходе САПР выдает программные и аппаратные средства для реализации элементов проектируемой системы. САПР включает в себя следующие модули:

• моделирования;

• сравнения;

• выбора средств.

В распоряжении САПР находятся базы данных, содержащие:

• информацию об угрозах (далее база угроз);

• модели угроз и модели использования (далее база моделей);

• результаты сравнения моделей (далее база результатов);

• варианты программной и аппаратной реализации элементов систем и комплексов (далее база средств).

В частном случае для реализации элементов системы выбираются и такие аппаратные средства, которые относятся к классу средств устойчивых к физическому воздействию, взлому, фальсификации (англ. anti-tamper, tamper resistance).

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

Например:

Вид угрозы. Элемент системы. Способ реализации угрозы: Вектор атаки.

Указанная база постоянно обновляется, в т.ч. аналитиками и специалистами по информационной безопасности, при выявлении ими новых видов угроз, способов их реализации и неизвестных ранее векторов атак; также расширяется перечень элементов системы уязвимых для того или иного вида угроз. Один и тот же вид угрозы (несанкционированное управление, несанкционированный доступ к информации, отказ в обслуживании и т.п.) относится к системе в целом и может быть реализован в отношении различных компонентов и других элементов системы, компрометируя как элементы в отдельности, так и систему в целом. Для различных элементов системы описания угроз могут повторяться, но атаки, влияние на систему, риски, связанные с угрозами и противодействие этим угрозам, могут быть различны. Для каждого элемента определенный вид угрозы может быть реализован разными способами, в том числе с задействованием других компонентов системы. Например, для вызова отказа в обслуживании камеры системы видеонаблюдения (в описании угрозы камера - это элемент системы) которая имеет выход в Интернет через веб-сервер, необходимо сначала скомпрометировать веб-сервер (см. Фиг. 2б WEB_VULN).

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

На Фиг. 3 изображена схема проектируемой системы видеонаблюдения, где камеры видеонаблюдения подключены к видеосерверам, осуществляющим прием, диспетчеризацию и хранение видеопотоков с этих камер. Для хранения используется хранилище. Доступ к видеопотокам в хранилище уполномоченными пользователями возможен как изнутри (через терминал), так и извне, через веб-сервер. Доступ к видеосерверу для управления системой возможен через терминал. Компоненты системы связаны посредством сетевого оборудования. Таким образом модель использования включает следующие виды использования (что отражено в модели Фиг. 2):

• управление системой, реализуемое через видеосервер со стороны терминала посредством аутентификации на видеосервере;

• доступ к видеопотокам, содержащимся в хранилище, реализуемое через хранилище, посредством аутентификации на веб-сервере;

• видеозапись, реализуемую через:

○ камеру, посредством аналогово-цифрового преобразования оптического сигнала (видеопотока) камерой (сокр. англ. ADC, на Фиг. 2 ADC);

○ видеосервер, посредством приема и обработки преобразованного сигнала (на Фиг. 2 RECEPTION/CONVERT);

○ хранилище, посредством сохранения принятого и обработанного сигнала (на Фиг. 2 SAVE).

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

База результатов - база данных, которая содержит результаты сравнения модели использования с моделью угроз, форма результата, содержащегося в базе зависит от вида моделей и способа сравнения. Например, для древовидных моделей это будут узлы и ветви, пример на Фиг. 4. На Фиг. 5 приведен пример результата сравнения (выполненного посредством пересечения) моделей, приведенных на Фиг. 2а и Фиг. 2б, который представляет из себя также древовидную модель. Данные примеры будут рассмотрены при описании модуля сравнения и модуля выбора средств.

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

Модуль моделирования предназначен для построения моделей использования и моделей угроз на основании описания архитектуры проектируемой системы. Построение модели необходимо для приведения описания угроз и описания использования к одному виду с целью осуществления сравнения. Модуль осуществляет построение модели использования на основании интересов уполномоченных пользователей относительно системы (в частном случае требований к системе), полученных на вход САПР в формализованном описании архитектуры. Такими интересами для проектируемой системы из примера на Фиг. 3, как можно понять, является эксплуатационный интерес, предполагающий следующее использование уполномоченным пользователем:

• видеозапись;

• управление системой видеозаписи;

• доступ к сохраненным видеопотокам.

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

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

• несанкционированное управление системой видеозаписи;

• несанкционированный доступ к сохраненным видеопотокам.

А также интересом может являться приведение системы в неработоспособное состояние - отказ в обслуживании.

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

Описание угрозы (как говорилось выше при описании базы угроз) указывает на элементы, через которые угроза реализуется и способы реализации угрозы (атака), а также векторы атаки. На основании этого модулем моделирования строится модель, пример которой изображен на Фиг. 2б. Для проектируемой системы из примера, изображенного на Фиг. 3 угрозами являются:

• неавторизированное управление, реализуемое через видеосервер за счет:

○ похищенного пароля (AUTH_PWD) авторизации на видеосервере, где векторами атак для данного способа являются:

■ эксплуатация уязвимости веб-сервера (WEB_VULN) для проникновения во внутреннюю сеть;

■ с последующим перехватом упомянутого пароля внутри сети (SNIFF);

• неавторизированный доступ, реализуемый через хранилище, за счет:

○ похищенного пароля (WEB_AUTH_PWD) авторизации на веб-сервере, где векторами атак для осуществления данного способа являются:

■ перехват упомянутого пароля (SNIFF) при прослушивании соединения между уполномоченным пользователем, получающим доступ из внешней сети, и веб-сервером;

○ эксплуатации уязвимости веб-сервера (WEB_VULN);

• отказ в обслуживании, реализуемый через камеру за счет:

○ исчерпания канала (CHANNEL_EXHAUSTION), где векторами атак для данного способа являются:

■ эксплуатации уязвимости сетевого оборудования, в частности веб-сервера (WEB_VULN) для прямого доступа к камерам из внешней сети;

■ с последующей распределенной атакой на камеры (DDOS) прямой доступ к которой получен.

Модуль сравнения предназначен для сравнения модели использования и модели угроз. Сам способ сравнения зависит от вида моделей. Для древовидных моделей используется пересечение, результат которого представлен на фигурах, где результатом сравнения являются модель (Фиг. 5) или части моделей (Фиг. 4) которые указывают:

- виды использования системы, отражающие только интерес нарушителя (Фиг. 4а);

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

- виды использования системы, отражающие интерес как нарушителя, так и уполномоченного пользователя и, реализуемые сходными способами (Фиг. 4в);

Также результат сравнения содержит способы реализации (требования к элементу системы) отражающие интерес уполномоченного пользователя (на Фиг. 4 изображены, а на Фиг 5 выделены пунктирными линиями).

На Фиг. 4а изображен вид использования, отражающий только интерес нарушителя. Такого вида использования, как отказ в обслуживании в модели использования нет, но отказ в обслуживании реализуется через элемент системы "камера", камера используется в модели использования для реализации интереса уполномоченного пользователя, поэтому результат сравнения дополнен информацией о способе реализации интереса уполномоченного пользователя (на Фиг. 4а это ADC), это будет учтено модулем выбора средств. Отказ в обслуживании реализуется посредством атаки на исчерпание канала (на Фиг. 4а CHANNEL_EXHAUSTION), которая возможна посредством эксплуатации уязвимости сетевого оборудования, например веб-сервера, (на Фиг. 4а WEB_VULN) для прямого доступа к камере из внешней сети, после чего осуществляется распределенная атака на камеру (на Фиг. 4а DDOS)

На Фиг. 4б отражен вид использования системы, отражающий интерес как нарушителя, так и уполномоченного пользователя, но реализуемый каждой из заинтересованных сторон различными способами. Такой вид использования как доступ отражает интерес как нарушителя, так и уполномоченного пользователя. Но способ реализации угрозы отличается от способа реализации использования, отражающего интерес уполномоченного пользователя. Для реализации угрозы используется эксплуатация уязвимостей веб-сервера (на Фиг. 4б отмечено как WEB_VULN). Хранилище используется в модели использования для реализации интереса уполномоченного пользователя (видеозапись), поэтому результат сравнения дополнен информацией о способе реализации интереса уполномоченного пользователя (на Фиг. 4б это SAVE), это будет учтено модулем выбора средств при определении требований к функциональным возможностям средств.

На Фиг. 4в отражены виды использования системы, отражающие интерес как нарушителя, так и уполномоченного пользователя и, реализуемые сходными способами. Такой вид использования как управление отражает интерес как нарушителя, так и уполномоченного пользователя. И реализовывается данное использование сходными способами, через авторизацию при помощи пароля на видеосервере (на Фиг. 4в AUTH_PWD), отличие состоит в том, как получен этот пароль. Нарушителем этот пароль получается за счет эксплуатации уязвимостей веб-сервера (WEB_VULN), что позволяет проникнуть в сеть, связывающую компоненты системы видеонаблюдения с последующим перехватом этого пароля в сети (SNIFF). Как WEB_VULN и SNIFF, на Фиг. 4в отмечены векторы атак. Такой вид использования как доступ отражает интерес как нарушителя, так и уполномоченного пользователя и может реализоваться нарушителем в том числе (а на Фиг. 4б отображена другой возможный способ реализации - эксплуатация уязвимости веб-сервера) способом сходным со способом использования уполномоченного пользователя через авторизацию при помощи пароля на веб-сервере. Нарушителем этот пароль получается за счет перехвата трафика (SNIFF), идущего к веб-серверу из внешней сети от уполномоченного пользователя.

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

• ограничивали виды использования системы, когда данный вид использования отражает только интересы нарушителя;

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

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

Таким образом, для случая, отраженного на Фиг. 4а, необходимо ограничить (в частном случае полностью исключить) вид использования (угрозу), отражающий интерес нарушителя, но так как этот вид использования реализуется через элемент "Камера", который используется также для реализации интересов уполномоченного пользования (видеозапись) это также необходимо учесть (на Фиг. 4а ADC). Используя указанные требования, модуль выбора средств обращается к базе средств с запросом, в котором указывается, что должно быть реализовано (в данном случае ADC), а что должно быть ограничено (в данном случае DDOS или WEB_VULN или CHANNEL_EXHAUSTION) или непосредственно исключено (вид использования - Отказ в обслуживании). В ответ на этот запрос база средств выдает возможные варианты, в данном примере это может быть камера типа BNC (англ. Bayonet Neill-Concelman), которая в принципе не подвержена атаке CHANNEL_EXHAUSTION.

Для случая, отраженного на Фиг. 4б, необходимо ограничить (в частном случае полностью исключить) способ реализации угрозы, такой как эксплуатация уязвимостей веб-сервера. Используя указанные требования, модуль выбора средств обращается к базе средств с запросом, в котором указывается, что должно быть ограничено в системе (в данном случае WEB_VULN). В ответ на запрос база средств может предложить использовать средство управления обновлениями (англ. Patch Manager) или средство противодействия эксплоитам (англ. Exploit Prevention.) или DMZ⁷ (⁷ ГОСТ Р ИСО/МЭК 27033-1-2011).

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

• источник или множество источников атаки,

• элемент или множество элементов, являющихся целью атаки;

• вид воздействия;

• средства воздействия.

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

Система, изображенная на Фиг. 1, используется для осуществления способа автоматизированного проектирования системы программных и аппаратных средств. Данный способ 600 изображен на Фиг. 6. Вначале на вход САПР на этапе 610 получает формализованное описание архитектуры проектируемой системы (далее система), включающее по меньшей мере:

• элементы системы, в том числе компоненты системы и связи между компонентами;

• интересы уполномоченных пользователей относительно системы.

На основании полученного описания на этапе 620 модулем моделирования строят модель использования включающую:

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

• элемент системы (далее элемент) через который реализуется такое использование;

• способ реализации данного вида использования через указанный элемент.

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

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

• элемент, через который реализуется данный вид угрозы;

• способ реализации угрозы через указанный элемент;

• вектор воздействия на систему для осуществления способа реализации угрозы.

Далее, на этапе 650, модуль сравнения извлекает из базы моделей построенные модели и сравнивают модель угроз с моделью использования способом сравнения, предназначенным для сравнения моделей данного вида, для определения:

• видов использования системы, отражающих только интерес нарушителя;

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

• видов использования системы, отражающих интерес как нарушителя, так и уполномоченного пользователя и, реализуемых сходными способами;

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

• ограничивали виды использования системы, когда данный вид использования отражает только интересы нарушителя;

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

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

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

Вариант реализации элементов проектируемой системы из примера изображен на Фиг. 7. Для обеспечения интересов уполномоченных пользователей и не возможности реализации угроз нарушителями ключевыми средствами при реализации архитектуры являются:

• камеры BNC;

• защищенный канал между уполномоченным пользователем и веб-сервером;

• DMZ зона, в которой расположен веб-сервер.

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

Поэтому система, изображенная на Фиг. 1, используется также для осуществления автоматизированного тестирования системы программных и аппаратных средств. Способ автоматизированного тестирования 800 изображен на Фиг. 8. Вначале на вход САПР на этапе 810 получает формализованное описание архитектуры тестируемой системы, включающее по меньшей мере:

• элементы системы, в том числе компоненты системы, связи между компонентами, а в частном случае программные и аппаратные средства их реализующие;

• интересы уполномоченных пользователей относительно системы.

На основании полученного описания на этапе 820 модулем моделирования строят модель использования включающую:

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

• элемент системы (далее элемент) через который реализуется такое использование;

• способ реализации данного вида использования через указанный элемент.

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

• функциональные возможности средства;

• способ конфигурирования средства и связь с другими средствами;

• модель или версия средства, тип средства;

• другие технические характеристики;

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

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

• элемент, через который реализуется данный вид угрозы;

• способ реализации угрозы через указанный элемент;

• вектор воздействия на систему для осуществления способа реализации угрозы.

Далее, на этапе 850, модуль сравнения извлекает из базы моделей построенные модели и сравнивает модель угроз с моделью использования способом сравнения, предназначенным для сравнения моделей данного вида, для определения:

• видов использования системы, отражающих только интерес нарушителя (видов несанкционированного использования);

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

• видов использования системы, отражающих интерес как нарушителя, так и уполномоченного пользователя и, реализуемых сходными способами;

В частном случае исходя из результатов сравнения на этапе 851 определяют рекомендованные для реализации средства, это может быть осуществлено, например, как в способе 600 на этапе 660. Далее на этапе 852 рекомендованные средства сравнивают со средствами реализующие элементы тестируемой системы. Также могут получаться в качестве рекомендаций не непосредственные средства, а их технические и другие характеристики, функциональные возможности или способы конфигурирования и т.д. и соответственно сравнение с реализованными средствами осуществляется по ним, для этого предварительно получают соответствующую информацию о реализованных средствах.

Модулем выбора средств на этапе 860 обнаруживают уязвимые средства тестируемой системы, которые уязвимы к угрозам⁸ (⁸ Виды использования системы, отражающие только интерес нарушителя), способу реализации угроз, векторам атаки. Уязвимость подразумевает то, что такие средства:

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

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

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

Невозможность ограничения определяется в частном случае функциональными возможностями или способом конфигурирования средств, при помощи которых реализованы элементы. В другом частном случае такая невозможность определяется версией программного средства (или моделью для аппаратного средства). Например, программное обеспечение веб-сервера версии 1.01 подвержен вектору атаки через эксплуатацию уязвимости CVE 2018 - ХХХХ при помощи эксплоита, а версия 1.02 такую возможность исключает, так как не содержит указанной уязвимости. Также невозможность может определятся типом средства. Например, камера типа IP может использоваться для DDoS-атаки, а также может быть сама ей подвержена, камера типа BNC такие возможности исключает.

Обнаружение уязвимых средств осуществляется за счет сопоставления реализованных средств (например, их типов, версий и т.д), их функциональных возможностей и способов конфигурирования с рекомендованными. Например, существует вид использования камеры в системе, отражающий интерес нарушителя-отказ в обслуживании. Чтобы ограничить данный вид использования к элементу камера в системе предъявляется требование (дается рекомендация) - средство для реализации элемента должно относится к типу BNC. Поэтому если камера будет относиться к типу IP модуль выбора средств при сравнении типов обнаружит несоответствие между типом средства в текущей реализацией и рекомендованным типом. Для получения требований к системе, на основании которых формируются рекомендации, осуществляется сравнение модели угроз и модели использования и на основании результатов сравнения модулем выбора средств формируется запрос для получения рекомендованных: средств, типов средств, версий средств и т.д. Для описываемого примера запрос указывает вид использования (угрозу), которое необходимо ограничить - отказ в обслуживании и элемент системы в отношении, которого данное использование необходимо ограничить - камера. В ответ на запрос от базы получают ответ, где рекомендованное средство для реализации элемента камера - камера типа BNC. Модуль выбора сравнит рекомендованный тип средств с текущей реализацией (полученной на этапах 810, 820) и, в случае несоответствия, обнаружит, что реализованное средство системы не ограничивает виды угрозы - т.е. система является уязвимой в результате отклонения текущей реализации от рекомендованной. Так модуль выбора средств проверит все элементы системы и сравнит требования к ним с текущей реализацией. Обоснованность вывода об уязвимости определяется актуальностью и полнотой базы средств и базы угроз. В зависимости от структуры базы и запроса ответ на запрос может содержать несколько рекомендованных моделей средств, типов средств, версий средств и т.д., где безопасное средство должно соответствовать хотя бы одной рекомендации. Например, модель реализованного средства не соответствует рекомендованным моделям (ввиду неполноты базы средств), но функциональные возможности или способы конфигурации соответствуют рекомендованным, следовательно, такое средство не признается уязвимым.

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

В настоящем изобретении под модулями САПР понимаются реальные устройства, системы, компоненты, группа компонентов, реализованных с использованием аппаратных средств, таких как интегральные микросхемы (англ. application-specific integrated circuit, ASIC) или программируемой вентильной матрицы (англ. field-programmable gate array, FPGA) или, например, в виде комбинации программных и аппаратных средств, таких как микропроцессорная система и набор программных инструкций, а также на нейроморфных чипах (англ. neurosynaptic chips) Функциональность модулей САПР может быть реализована исключительно аппаратными средствами, а также в виде комбинации, где часть функциональности реализована программными средствами, а часть аппаратными. В некоторых вариантах реализации часть модулей САПР может быть исполнена на процессоре компьютера общего назначения (например, который изображен на Фиг. 5). Базы данных могут быть реализованы всеми возможными способами и содержаться как на одном физическом носителе, так и на разных, располагаться как локально, так и удаленно.

Фиг. 8 представляет пример компьютерной системы общего назначения, персональный компьютер или сервер 20, содержащий центральный процессор 21, системную память 22 и системную шину 23, которая содержит разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, которая способна взаимодействовать с любой другой шинной архитектурой. Системная память содержит постоянное запоминающее устройство (ПЗУ) 24, память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами персонального компьютера 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Персональный компьютер 20 в свою очередь содержит жесткий диск 27 для чтения и записи данных, привод магнитных дисков 28 для чтения и записи на сменные магнитные диски 29 и оптический привод 30 для чтения и записи на сменные оптические диски 31, такие как CD-ROM, DVD-ROM и иные оптические носители информации. Жесткий диск 27, привод магнитных дисков 28, оптический привод 30 соединены с системной шиной 23 через интерфейс жесткого диска 32, интерфейс магнитных дисков 33 и интерфейс оптического привода 34 соответственно. Приводы и соответствующие компьютерные носители информации представляют собой энергонезависимые средства хранения компьютерных инструкций, структур данных, программных модулей и прочих данных персонального компьютера 20.

Настоящее описание раскрывает реализацию системы, которая использует жесткий диск 27, сменный магнитный диск 29 и сменный оптический диск 31, но следует понимать, что возможно применение иных типов компьютерных носителей информации 56, которые способны хранить данные в доступной для чтения компьютером форме (твердотельные накопители, флеш карты памяти, цифровые диски, память с произвольным доступом (ОЗУ) и т.п.), которые подключены к системной шине 23 через контроллер 55.

Компьютер 20 имеет файловую систему 36, где хранится записанная операционная система 35, а также дополнительные программные приложения 37, другие программные модули 38 и данные программ 39. Пользователь имеет возможность вводить команды и информацию в персональный компьютер 20 посредством устройств ввода (клавиатуры 40, манипулятора «мышь» 42). Могут использоваться другие устройства ввода (не отображены): микрофон, джойстик, игровая консоль, сканнер и т.п. Подобные устройства ввода по своему обычаю подключают к компьютерной системе 20 через последовательный порт 46, который в свою очередь подсоединен к системной шине, но могут быть подключены иным способом, например, при помощи параллельного порта, игрового порта или универсальной последовательной шины (USB). Монитор 47 или иной тип устройства отображения также подсоединен к системной шине 23 через интерфейс, такой как видеоадаптер 48. В дополнение к монитору 47, персональный компьютер может быть оснащен другими периферийными устройствами вывода (не отображены), например, колонками, принтером и т.п.

Персональный компьютер 20 способен работать в сетевом окружении, при этом используется сетевое соединение с другим или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 являются такими же персональными компьютерами или серверами, которые имеют большинство или все упомянутые элементы, отмеченные ранее при описании существа персонального компьютера 20, представленного на Фиг. 8. В вычислительной сети могут присутствовать также и другие устройства, например, маршрутизаторы, сетевые станции, пиринговые устройства или иные сетевые узлы.

Сетевые соединения могут образовывать локальную вычислительную сеть (LAN) 50 и глобальную вычислительную сеть (WAN). Такие сети применяются в корпоративных компьютерных сетях, внутренних сетях компаний и, как правило, имеют доступ к сети Интернет. В LAN- или WAN-сетях персональный компьютер 20 подключен к локальной сети 50 через сетевой адаптер или сетевой интерфейс 51. При использовании сетей персональный компьютер 20 может использовать модем 54 или иные средства обеспечения связи с глобальной вычислительной сетью, такой как Интернет. Модем 54, который является внутренним или внешним устройством, подключен к системной шине 23 посредством последовательного порта 46. Следует уточнить, что сетевые соединения являются лишь примерными и не обязаны отображать точную конфигурацию сети, т.е. в действительности существуют иные способы установления соединения техническими средствами связи одного компьютера с другим.

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

1. Способ тестирования системы программных и аппаратных средств системой автоматизированного проектирования (далее САПР), в котором модули САПР:

а) получают формализованное описание архитектуры тестируемой системы, на основании которого:

- строят модель использования включающую: вид использования системы, отражающий интерес уполномоченного пользователя; элемент системы (далее элемент), через который реализуется такое использование; способ реализации данного вида использования через указанный элемент;

б) получают из базы угроз формализованное описание известных угроз для систем, сходных с тестируемой, на основании которого:

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

в) сравнивают модель угроз с моделью использования способом сравнения, предназначенным для сравнения моделей данного вида, для определения видов использования системы, отражающих:

- только интерес нарушителя (вид несанкционированного использования);

- интерес как нарушителя, так и уполномоченного пользователя, но, реализуемых каждой из заинтересованных сторон различными способами;

- интерес как нарушителя, так и уполномоченного пользователя и, реализуемых сходными способами;

г) на основании результатов сравнения моделей обнаруживают средства тестируемой системы, которые уязвимы:

- к виду несанкционированного использования системы (далее указанный вид несанкционированного использования);

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

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

2. Способ по п. 1, в котором формализованное описание архитектуры содержит по меньшей мере: элементы системы, в том числе компоненты системы, связи между компонентами, а также программные и аппаратные средства их реализующие.

3. Способ по п. 1, где сходной признается система, имеющая то же назначение или по меньшей мере один тождественный элемент.

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

5. Способ по п. 1, в котором:

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

- уязвимым к указанному способу реализации угрозы признается средство, которое не ограничивает указанный способ реализации угрозы;

- уязвимым к указанному вектору воздействия на систему признается средство, которое не ограничивает указанный вектор воздействия на систему.

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

7. Способ по п. 1, в котором дополнительно на основании сравнения моделей определяют программные и аппаратные средства, рекомендованные для реализации элементов системы, которые по меньшей мере:

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

- ограничивают указанный способ реализации угрозы;

- ограничивают указанный вектор воздействия на систему.

8. Способ по п. 7, в котором уязвимыми средствами тестируемой системы являются средства, несоответствующие рекомендованным средствам.

9. Способ по п. 7, в котором дополнительно сравнивают определенные рекомендованные средства со средствами тестируемой системы.

10. Способ по п. 9, в котором сравнение средств осуществляется путем сравнения версии средства или типов средств.

11. Способ по п. 10, в котором в котором уязвимыми средствами признаются средства, тип или версия которых отсутствуют среди рекомендованных.

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

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

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

15. Способ по п. 14, в котором уязвимыми средствами признаются средства, функциональные возможности или способы конфигурирования которых отсутствуют среди рекомендованных.