Дефекты программного обеспечения системы управления движением судов



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

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

Согласно ГОСТам и другим нормативно-правовым документам РФ отдельного понятия для программной ошибки, программного дефекта или уязвимости в программном коде не существует, однако в [1] дефект или ошибка определяется как каждое отдельное несоответствие продукции установленным к ней требованиям. Помимо этого, этот же документ определяет термин тестирование. Тестирование — деятельность, направленная на обнаружение дефектов в программном обеспечении.

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

Защищаемая информация — информация, являющаяся предметом собственности и подлежащая защите в соответствии с требованиями правовых документов или требованиями, устанавливаемыми собственником информации [2].

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

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

Согласно приведенным определениям, дефекты ПО можно разделить на:

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

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

Рис. 1. Классификация дефектов ПО

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

Актуальная общепринятая классификация дефектов по типам представлена в базе Common Weakness Enumeration [4], список зарегистрированных дефектов — в базе Common Vulnerabilities and Exposures организации MITRE [5]. Наиболее распространенными типами дефектов являются:

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

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

– ошибки обработки пользовательских данных;

– ошибки форматных строк;

– ошибки синхронизации (взаимные блокировки, отсутствующие блокировки и т. п.);

– утечки памяти и других ресурсов системы;

– некорректная работа с временными файлами и другими интерфейсами ОС;

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

Уязвимости могут быть классифицированы с помощью различных подходов. Dowd и другие в своей работе [6] выделили уязвимости в три базовых класса в зависимости от этапа разработки:

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

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

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

Рассмотрим последствия дефектов программного обеспечения на примере системы управления движением судов (СУДС).

СУДС работает согласно международным и национальным правовым и нормативным актам, над повышением уровня безопасности мореплавания путем сбора, обработки информации и выдачи ее на суда, оказание помощи в судовождении и организации движения объектов по акватории, которая оборудована современными средствами радиолокации, связи, телевидения и программно-аппаратными комплексами [7]. Под программно-аппаратными комплексами (ПАК) понимаем программное обеспечение, вычислительную технику и локальную вычислительную сеть. Программное обеспечение (ПО) — совокупность программ для управления процессом работы компьютера. В него входят: операционная система и вспомогательные программы.

На основании Приказа Министерства транспорта РФ от 23 июля 2015г. № 226 «Об утверждении Требований к радиолокационным системам управления движением судов, объектам инфраструктуры морского порта, необходимым для функционирования Глобальной морской системы связи при бедствии и для обеспечения безопасности, объектам и средствам автоматической информационной системы, службе контроля судоходства и управления судоходством», программное обеспечение, используемое в СУДС, должно иметь свидетельство об одобрении типа аппаратуры, выданное Федеральным агентством речного и морского транспорта РФ [8].

На сегодняшний день в России функционируют 16 СУДС, программное обеспечение которых представлено в таблице 1 (рис. 2).

Таблица 1

Местонахождения СУДС	Наименование программного обеспечения
	Балтика	Sea Track	Navi Harbour, версия							PWS — 9000
			3.71	3.97	4.20	4.22	4.30	4.31	4.40
порт Архангельск	+
порт Туапсе								+
порт Калининград					+
порт Высоцк									+
порт Ванино									+
Большой порт Санкт-Петербург						+
порт Оля						+
порт Астрахань						+
порт Кавказ							+
порт Владивосток								+
порт Посьет								+
порт Зарубино								+
порт Усть-Луга									+
СУДС Кольского залива	+									+
Прибрежная СУДС восточной части Финского залива						+
порт Сочи						+
порт Тамань										+
порт Находка								+
порт Восточный								+
порт Приморск					+
порт Магадан		+
порт Темрюк							+
порт Таганрог					+
порт Азов					+
порт Махачкала			+
порт Новороссийск				+
ИТОГО:	2	1	1	1	4	5	2	6	3	2

Рис. 2. Статистика используемого программного обеспечения СУДС в РФ

Для СУДС целесообразно выделять две стороны программного обеспечения: программную надежность объекта — свойство объекта выполнять заданные функции, обусловленное качеством программного обеспечения; надежность программного обеспечения — свойство программного обеспечения выполнять предписанные ему требования [9].

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

Так, например, в процессе эксплуатации ПАК СУДС порта Новороссийск, возникали следующие виды отказов (рис. 3) [7]:

– программные, вызванные дефектами ПО, несовместимостью системного и другого программного обеспечения;

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

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

Рис. 3. Процентное соотношение видов отказов технических средств СУДС

Последствиями таких отказов стали:

– сброс целей на оперативно-дисплейном модуле (ОДМ) продолжительностью от 5 мин. до 2ч. 34мин.;

– фиксирование береговыми радиолокационными станциями (БРЛС) «ложных целей»;

– БРЛС не осуществляла захват целей, т. е. не выдавала их координат;

– автоматическая идентификационная система (АИС) не захватывала цели, т. е. не выдавала их координат;

– отсутствие информации о местонахождении судов из-за отказа интегратора;

– сбой при исполнении программ. Под сбоем понимаем кратковременное нарушение работоспособности системы, после которого работоспособность восстанавливается оператором без проведения ремонта или самовосстанавливается (перезагрузка компьютера по причине «подвисания») длительностью 3–20 мин. (в момент перезагрузки компьютера данных о судах нет).

В процессе обработки данных от БРЛС и АИС приоритетными являются данные от БРЛС, поэтому любой отказ в программном обеспечении БРЛС приведет к «зависанию» сервера данных СУДС, т.о., некоторое время информация о целях будет отсутствовать, что не позволит контролировать и оперативно принимать решение о судоходной обстановке в районе действия СУДС.

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

Литература:

1. ГОСТ Р. 27.002–2009. Надежность в технике. Термины и определения — М.: ВНИИМАШ, 2009–3 с.
2. ГОСТ Р 50922–2006 Защита информации. Основные термины и определе-ния — М.: Стандартинформ, 2008–12 c.
3. Аветисян, А. И. Современные методы статического и динамического анализа программ для решения приоритетных проблем программной инженерии: автореф. дис. … д-ра физ.-мат. наук: 05.13.11/Аветисян А. И. — М., 2011. — 36 с.
4. База Common Weakness Enumeration [Электронный ресурс]. — Режим доступа: http://cwe.mitre.org.
5. База Common Vulnerabilities and Exposures [Электронный ресурс]. — Режим доступа: http://cve.mitre.org
6. Dowd, M. The art of software security assessment: Identifying and preventing software vulnerabilities / M. Dowd, J. McDonald, J. Schuh — Boston, USA: Addison-Wesley Professional, 2006–1244 p.
7. Тюфанова, А. А. Методика анализа эксплуатационной надежности технических средств системы управления движением судов на примере порта Новороссийск/ А. А. Тюфанова. — Казань: Изд-во «Бук», 2015. — 104 C.
8. Приказ Министерства транспорта РФ от 23 июля 2015г. № 226 «Об утверждении Требований к радиолокационным системам управления движением судов, объектам инфраструктуры морского порта, необходимым для функционирования Глобальной морской системы связи при бедствии и для обеспечения безопасности, объектам и средствам автоматической информационной системы, службе контроля судоходства и управления судоходством».
9. Голинкевич, Т. А. Прикладная теория надежности: Учебник для вузов/ Т. А. Голинкевич — М.: Высшая школа, 1985. — 203 C.