Актуальность вопросов тестирования безопасности и защищённости программных продуктов

         2. Угрозы со стороны пользователей ПП:

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

       Конфликт  интересов между пользователями ПП, а также между пользователями ПП и пользователями КС, в которых эксплуатируется ПП.

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

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

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

       При этом следует отметить, что разработчик  прикладного ПП, при выборе технологий, при помощи которых он собирается разрабатывать свой ПП — сам становится потребителем информационных технологий. Т.е. проблема обеспечения безопасности и защищённости информационных технологий в данном случае беспокоит его как пользователя этих технологий. Т.е. на разработчика прикладного ПП также могут распространяться такие угрозы со стороны разработчиков ИТ, как умышленное и неумышленное внесение «закладок»/ошибок в ИТ, а со стороны разработчика прикладного ПП – нелегальное использование и кража интеллектуальной собственности разработчиков ИТ.

Принципы безопасности и защищённости программных продуктов.

Основными принципами безопасности безопасных и  защищенных ПП можно назвать:

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

Категории объектов защиты программных продуктов 

       В качестве основных категорий объектов защиты ПП хотелось бы выделить:

• данные;
• информация;
• функции ПП;

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

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

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

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

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

Уровни  представления программных продуктов  с позиции информационной безопасности 

Рассматривать ПП можно, как:

• набор данных (как это диктует определение ГОСТ, т.е. рассматривать ПП как набор файлов, из которых он состоит);
• множество потоков данных, когда ПП выполняется (обычно такие потоки описываются в виде data- flow диаграмм на этапе разработки ПП). Необходимо следить, чтобы ни что не препятствовало нормальному ходу потоков, а также, чтобы неавторизованные субъекты или процессы не смогли читать или модифицировать (удалять) данные из потоков, а авторизованным пользователям и процессам не было отказано в доступе к ним (требование также относится и к данным, которые находятся в процессе пересылки);
• набор функций (сервисов). Необходимо обеспечить разграничение доступа к функциям ПП, а также обеспечить меры по сохранению доступности, правильности и надёжности работы этих функций;
• предмет договорных отношений между разработчиком ПП и пользователем (разработчик может внести в ПП некоторые функции, которые отслеживают выполнение условий договора со стороны пользователей ПП, а пользователи могут пытаться обойти или отключить эти функции);
• часть некоторой КС, в которой выполняется ПП. Продукт должен быть безопасным для самой КС и её пользователей и в то же время, ПП и его данные должны быть защищёны от неавторизованных процессов и пользователей в рамках данной КС.

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

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

Вопросы обеспечения гарантий безопасности и защищённости программных продуктов 

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

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

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

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

       Рис. 1 – Зависимость прибыли разработчика от степени защищённости ПП 

       Попытка обеспечить безопасность ПП при помощи какой-то другой программы приводит к аналогичной проблеме — необходимости обеспечения безопасности, но на этот раз уже второй программы («синдром Мюнхгаузена»). В результате, можно сделать вывод:

       Безопасность  программных средств не может  быть реализована только на программном  уровне.

       На практике для обеспечения безопасности и защищённости ПП (в общем случае) применяются средства и методы различных уровней:

• Нормативно-правовой. Уровень стандартов и законов, которые регламентируют отношения между лицами, заинтересованными в разработке, эксплуатации и распространении ПП. Одним из средств этого уровня можно назвать «лицензионное соглашение», с которым соглашается пользователь ПП при его установке и использовании.
• Административно-организационный. Данный уровень включает ряд мер, в том числе те, которые разработчик ПП считает необходимым реализовать в КС пользователя ПП, описывает их в документации к ПП (документы вида «Руководство по безопасной установке и настройке ПП») и передаёт пользователю. Выполнение этих мер, а также дальнейшая поддержка продукта зачастую ложится на плечи пользователя. Административно-организационные меры, как правило, позволяют наиболее эффективно справляться со скоростью изменения информационных технологий, ростом числа вирусов, видов «хакерских» атак и т.д.
• Экономический. Использование невысокой цены для ПП достаточно часто является довольно эффективной мерой для сдерживания объёма «пиратского» рынка. Многие пользователи, в случае, если цена лицензионной копии продукта не многим превосходит стоимость «пиратской» копии, предпочитают приобретать легальные копии продуктов.
• Морально-этический. Уровень включает в себя, например, ряд мер по усилению репутации легальных пользователей и дискредитации «чёрных»-распространителей («пиратов») нелицензионных копий ПП (примеры реализации данных мер: социальная реклама в средствах массовой информации, конкурс компании Microsoft на лучшее литературное произведение о честно купленном программном обеспечении и т.д.).
• Физический. Уровень включает меры физического разграничения доступа к ВУ, на которых инсталлирован ПП.
• Программно-технический. Сюда относятся различные электронные устройства и специальные программы, которые реализуют самостоятельно или в комплексе с другими средствами следующие способы защиты: идентификацию и аутентификацию субъектов (пользователей, процессов и объектов), разграничение доступа к ресурсам КС, контроль целостности данных, обеспечение конфиденциальности данных, регистрацию и анализ событий, происходящих в ПП.