Главная | Новости | Информация | Статьи | Программы Законы | Ссылки | О проекте | Off topic |
|
Главная | Новости | Информация | Статьи | Программы Законы | Ссылки | О проекте | Off topic |
В статье описывается краткая история проблемы теневого оборота
программных продуктов, а также приводится обобщённая процедура проектирования и
разработки систем программно-технической защиты программного обеспечения.
Предложенная процедура является реализацией технологического подхода к
разработке систем защиты, позволяющей спроектировать и программно реализовать
систему защиты с заранее заданными характеристиками и минимальными побочными
эффектами.
Проблема несанкционированного использования и распространения программного обеспечения (ПО) стала объектом исследований ещё в конце 70-х годов XX столетия и не теряет своей актуальности до сих пор. Причиной этому послужило стремительное развитие рынка персональных ЭВМ и, в особенности, признание IBM-совместимых компьютеров стандартом de facto для пользователей ПЭВМ. Таким образом, была разрешена проблема аппаратной и программной совместимости в рамках парка персональных компьютеров, что стимулировало появление программных продуктов “широкого пользования”, которые стали разрабатываться и распространяться в отрыве от конкретных систем автоматизированной обработки данных. Подобные продукты были, фактически, реализацией типовых программных решений в наиболее популярных областях автоматизации обработки данных (обработка текстов, создание расчётных таблиц, работа с базами данных, редактирование графических изображений, компьютерные игры; позднее появились системы трёхмерного моделирования и анимации, мультимедийные приложения, системы распознавания текста и речи и мн.др.). Таким образом, производители программного обеспечения получили возможность перейти от индивидуального проектирования систем обработки данных к типовому, что позволило существенно снизить расходы на разработку ПО, а также распределить расходы на его приобретение между значительным количеством пользователей.
С другой стороны, высокая распространённость микрокомпьютерных систем, персональное пользование программными средствами и фактическая неподконтрольность индивидуальных пользователей создали предпосылки (и техническую возможность) для интенсивного несанкционированного обмена программами между владельцами персональных компьютеров. Этому же способствовало и отсутствие устоявшихся моральных норм в отношении программных продуктов, несовершенство правовой базы, а также инерционное восприятие программного обеспечения как бесплатного компонента (включённого в стоимость) приобретённых аппаратных средств.
Экономические потери производителей программных продуктов, выражающиеся в виде упущенной выгоды и морального ущерба, обусловили необходимость разработки и применения мер, препятствующих теневому обороту программных продуктов. Указанные меры можно условно подразделить на законодательные (лоббирование законов, регламентирующих ответственность за несанкционированное использование и распространение ПО), организационные (установление контроля над пользователями путём регистрации их персональных данных, персонального режима обновления версий продукта и т.п.) и технические (использование программно-технических средств, препятствующих несанкционированному использованию и/или копированию программных продуктов).
В силу того, что лоббирование законов возможно лишь для крупных компаний или объединений производителей ПО, а организационные меры требуют значительных затрат на реорганизацию торговой инфраструктуры и могут привести к переходу части клиентов на продукты конкурентов, не применяющих таких мер, самыми популярными стали технические меры противодействия теневому обороту ПО. Таким образом, получили широкое распространение системы программной защиты ПО, основной целью которых было техническое противодействие несанкционированному использованию и распространению программных продуктов. Такое положение дел сохранилось, в целом, и до настоящего времени, не смотря на то, что производителями достаточно активно используются законодательные и организационные меры защиты своих программных продуктов.
По проблемам программно-технической защиты программного обеспечения от несанкционированного введения в хозяйственный оборот было опубликовано очень значительное число работ [1, 2, 3, 5, 9, 10]. В то же время, в многочисленных публикациях описывается техника, приёмы, но не технология (методология) защиты программных продуктов. Автору до настоящего времени не удалось найти публикации, которые были бы посвящены описанию обобщённой процедуры проектирования и реализации систем защиты программного обеспечения (СЗПО), как это делается, например, в области разработки программного обеспечения или проектирования подсистем защиты информации в системах обработки данных. По нашему мнению, отсутствие подобного описания в значительной мере затрудняет разработку СЗПО отдельными производителями, не имеющими соответствующего опыта, ведёт к многократному дублированию проводимых НИОКР, а также может быть причиной низкой стойкости разрабатываемых систем защиты.
Настоящий материал призван ликвидировать существующее «белое пятно» в исследованиях, посвящённых программно-технической защите программных продуктов.
По нашему мнению, процесс проектирования и разработки СЗПО можно логически разбить на следующие этапы:
Опишем указанные этапы более подробно.
Выявление целей и задач, стоящих перед производителем ПО. На этом этапе необходимо определить начальные условия, исходя из которых будет разрабатываться система защиты ПО. Среди возможных целей, преследуемых производителем ПО, могут быть: максимизация прибыли от продаж программного продукта, минимизация потерь от «пиратства», вытеснение конкурирующих продуктов с сегмента рынка, выход на новый сегмент рынка и др. Задачами же могут являться: защита единичного продукта, защита серии продуктов, создание системы защиты, которую в дальнейшем можно было бы предложить как самостоятельный продукт и др. Информация о целях и задачах определяет весь дальнейший процесс разработки СЗПО.
Согласование допустимого процента потерь от «пиратства». Данный этап, вкупе с первым, позволяет определить основное направление работы по созданию системы защиты. Как правило, фирма-производитель ПО обладает данными о теневом распространении своих продуктов. Кроме того, производители регулярно проводят маркетинговые исследования, дающие информацию о плановом объёме продаж продукта. Сведения о теневом распространении продукта, а также о разнице между планировавшимся и реальным объёмами продаж позволяют достаточно точно оценивать фактический процент потерь от «пиратства». На указанном же этапе определяется процент потерь, с которым производитель готов смириться (это может быть и 0%) [7].
Определение соответствующего требованиям уровня защиты. Требования к уровню защиты можно оценивать двояко: либо определять значения частных критериев устойчивости защиты к атакам и их весовые коэффициенты, чтобы рассчитать комплексный критерий устойчивости [8]; либо определять временной интервал, в течение которого СЗПО гарантированно будет препятствовать теневому распространению защищаемого продукта [6]. Эти два вида оценки уровня защиты сильно взаимосвязаны, в то же время, более наглядным, а также более удобным для сопоставления с запланированным уровнем потерь от «пиратства» является второй. Обладая данными о динамике продаж во времени, нетрудно рассчитать необходимый временной интервал живучести СЗПО, который позволит сократить потери до запланированного уровня.
Выявление функциональной направленности защищаемого продукта. Данная информация позволяет оценивать нетехнические факторы, связанные с возможностью теневого распространения защищаемого программного продукта. К таким факторам можно отнести: распространённость и популярность продукта, условия использования, вероятность превращения пользователя в злоумышленника, вероятность уличения недобросовестных пользователей, роль документации и поддержки при использовании продукта. В частности, широко распространённый и популярный продукт вызывает у злоумышленников намного больший интерес, нежели продукт, используемый ограниченной группой пользователей, кроме того, для менее популярных продуктов снижается вероятность быстрого попадания продукта в руки злоумышленников; нелегальное использование программного продукта юридическим лицом гораздо легче выявить, чем подобное использование лицом физическим и т.п. Функциональная же направленность продукта во многом определяет озвученные нетехнические факторы. Например, программная система ведения бухгалтерского учёта находится в значительной зависимости от документации и сопровождения, менее популярна, чем текстовые реакторы и табличные процессоры, в то же время, подобные системы относятся к распространённым, наиболее вероятный пользователь – юридическое лицо, место установки – компьютер в офисе и т.д.
Анализ предполагаемого протокола передачи ПО пользователю. На данном этапе уточняется состав организационных мер, связанных с коммерческой реализацией программного продукта: сбор персональных данных о пользователе или сохранение его анонимности, розничная (или наложенным платежом) продажа продукта за наличные либо продажа через глобальную сеть с электронными расчётами, наличие скидок на новые версии для зарегистрированных пользователей либо скидки на «кумулятивное» обновление для пользователей, перешедших с конкурирующих программных продуктов. Все эти данные позволяют оценить реально необходимый уровень стойкости системы защиты: если продукт распространяется индивидуально, то несанкционированное распространение такого «именного» продукта приведёт к уличению соответствующего пользователя (соответственно, уровень технической защиты продукта может быть средним), при распространении ПО через сеть Интернет и анонимности пользователей такая вероятность минимальна (следовательно, СЗПО должна иметь максимальный уровень стойкости).
Анализ возможных и вероятных угроз безопасности ПО. Этот этап представляет собой процедуру оценки и управления рисками, связанными с защитой программного продукта от несанкционированного использования и распространения [6]. Данная процедура включает: определение множества возможных угроз; выделение подмножества вероятных угроз; определение потенциального ущерба по каждой угрозе; выработка контрмер; разработку общей стратегии поведения в условиях риска. Среди угроз несанкционированного распространения продукта можно выделить: распространение похищенной у легального пользователя аутентичной информации (пароль, серийный код); подбор этой информации; преодоление системы технической защиты продукта; сетевую атаку на сервер глобальной сети с целью завладения дистрибутивом продукта; похищение дистрибутива у легального пользователя; превращение легального пользователя в злоумышленника; приобретение продукта злоумышленниками «в складчину»; и приобретение продукта по украденной или фальшивой кредитной карте.
Определение стратегии защиты программного продукта (меры и средства). На основе полученных на предыдущих этапах аналитических данных необходимо определить оптимальное для данной ситуации сочетание мер и средств защиты программного продукта. В рамках законодательных мер можно говорить лишь о механизмах повышения раскрываемости нарушений прав производителя продукта, организационные меры определяются оговоренным ранее протоколом передачи продукта пользователю. В рамках же технических мер можно говорить не только о как таковой СЗПО, но и средствах отслеживания фактов появления нелицензионных версий продукта в глобальной сети, технических средствах выявления злоумышленников и т.п. Таким образом, данный этап определяет роль и место СЗПО в комплексе мер по защите продукта.
Анализ исходных текстов продукта. Целью данного этапа является поиск потенциальных мест размещения элементов системы защиты, определение оптимального режима её маскировки, выявление возможных слабых мест в коде продукта, определение основных алгоритмов продукта, степени влияния на них системы защиты и возможности их модификации для использования для дополнительной защиты. Кроме этого, определяется язык программирования, на котором реализован программный продукт, а также стиль программирования и основные соглашения по построению исходного кода. В частности, нередко так называемые демонстрационные версии программных продуктов, распространяемые бесплатно, строятся из исходного кода полнофункциональных версий с внесением незначительных изменений, отключающих расширенную функциональность. В этом случае злоумышленники получают возможность, обратив эти изменения, получить аналог полнофункционального продукта. Проводимый анализ позволяет избежать подобных ситуаций.
Выбор оптимального типа СЗПО. Системы внешнего типа наиболее удобны для производителя ПО, так как легко можно защитить уже полностью готовый и оттестированный продукт. С другой стороны стойкость этих систем достаточно низка (в зависимости от принципа действия СЗПО), так как для обхода защиты достаточно определить точку завершения работы "конверта" защиты и передачи управления защищенной программе. Встраиваемые системы менее удобны для производителя ПО, так как возникает необходимость обучать персонал работе с программным интерфейсом системы защиты с вытекающими отсюда денежными и временными затратами, кроме того, усложняется процесс тестирования ПО и снижается его надежность. Но такие системы являются более стойкими к атакам, потому что здесь исчезает четкая граница между системой защиты и как таковым продуктом. Комбинированные же системы содержат элементы обоих типов [5].
Выбор оптимального вида СЗПО. На данном этапе производится выбор конкретного вида системы защиты. Иными словами, разработчики выбирают: устанавливать систему защиты от копирования («привязка» к ПК пользователя, к дистрибутивному носителю, физической дорожке жёсткого диска пользователя и т.п.) или систему защиты от использования (запрос пароля/серийного кода, ключевого файла, ключевого диска, электронного ключа). Например, львиная доля компьютерных игр использует «привязку» к дистрибутивному носителю (оптический диск), популярные отечественные программы ведения бухгалтерского и финансового учёта, ПО для разработки смет, архитектурного и инженерного проектирования используют защиту с электронным ключом, офисные пакеты используют защиты серийным кодом. Как правило, выбор зависит от большого числа факторов, определённых на более ранних этапах процесса разработки СЗПО. Многое, также, зависит и от соотношения стоимости копии программного продукта и стоимости копии системы его защиты.
Выработка рекомендаций по модификации исходных кодов для соответствия требованиям безопасности. Принятые ранее решения по типу и виду разрабатываемой СЗПО дают возможность формирования конкретных рекомендаций по видоизменению исходного кода продукта (без изменения функциональности) в соответствии с требованиями системы защиты. При этом изменению могут подлежать не только конструкции языка программирования, но и параметры компиляции исходных текстов. Например, статическое подключение библиотечных модулей вместо динамического или наоборот. Как правило, подобные изменения в исходном коде, кроме касающихся непосредственного размещения элементов системы защиты, связаны с затруднением анализа общей логики работы продукта и маскировкой расположения и проявлений СЗПО [8].
Первичное тестирование программного продукта. На данном этапе определяются наиболее важные потребительские характеристики программного продукта, набор его важнейших функций, подлежащие тестированию. Результаты тестов являются эталоном, с которым впоследствии будут сравниваться результаты тестов защищённого программного продукта. Разумеется, первичным это тестирование является для процесса разработки системы защиты ПО. Определённая часть тестов должна проводиться в рамках процесса разработки самого программного продукта. Таким образом, значительная часть этого этапа должна быть уже выполнена ранее.
Следующие три этапа (Оценка общих планируемых затрат на разработку и внедрение СЗПО, Оценка планируемого снижения потерь от «пиратства» и Принятие решения о целесообразности применения проектируемой СЗПО) сильно связаны друг с другом и преследуют цель – оценить реальные затраты на разработку системы защиты и сравнить их с дополнительным доходом, который будет получен в результате её применения. То есть, указанные этапы включают оценку ожидаемой экономической эффективности разрабатываемой СЗПО и принятие решения о применимости системы с найденной расчётной эффективностью. Оценка затрат на разработку СЗПО выполняется по существующим методикам расчёта стоимости разработки системного ПО. Сумма дополнительного дохода от снижения уровня «пиратства» рассчитывается на основе данных о разнице между текущим и планируемым процентом потерь. Решение же о целесообразности применения спроектированной СЗПО принимается исходя из общепринятого в экономике предположения о рациональном поведении экономических агентов, т.е. применение системы принимается целесообразным, если затраты на СЗПО не превышают выигрыша от её применения.
Доработка спецификаций СЗПО либо приобретение сторонней разработки, удовлетворяющей спецификации. В случае, если расчётные затраты на разработку СЗПО превышают сумму выигрыша от внедрения защиты, возможны два варианта. Первым вариантом является уточнение и оптимизация требований к СЗПО, в результате проведения которых стоимость системы защиты станет удовлетворительной. Другим вариантом может быть приобретение разработанной другими производителями системы защиты, удовлетворяющей спецификациям и требованиям по стоимости. Как правило, в недорогих программных продуктах используются приобретённые системы защиты (внешнего типа), в программных продуктах с высокой стоимостью часто применяются системы защиты собственной разработки или доработанные приобретённые системы защиты комплексного типа (электронный ключ).
Три последующих этапа (Разработка и оптимизация алгоритма СЗПО, Выбор языка программирования для реализации СЗПО, Программная реализация СЗПО и её тестирование) относятся к реализации системы защиты собственными силами производителя ПО. В целом, разработка программной системы защиты ПО практически не отличается от разработки произвольного программного продукта системного уровня, за исключением специфических требований по надёжности и устойчивости к статическому и динамическому анализу. Что же касается тестирования, то кроме свойственных обычным приложениям тестов, призванных выявить ошибки программирования, СЗПО должна подвергаться серии интенсивных тестов на устойчивость к атакам. Эти тесты основаны на так называемом «диверсионном подходе», который предполагает исследование системы защиты с позиций злоумышленника с использованием соответствующего инструментария [4], с целью её преодоления [8]. Для подобного тестирования СЗПО применяют к тестовой программе (либо написанной самостоятельно, либо стандартной, например, «Блокнот Windows»).
Применение СЗПО к продукту и проверка влияния защиты на показатели функциональности защищаемого ПО. На этом этапе выполняются проверки на побочные эффекты применения системы защиты к реальному защищаемому продукту. В данном случае должны быть повторены все тесты, выполненные на этапе первичного тестирования программного продукта. Затем, результаты повторных тестов должны сравниваться с результатами первичных тестов с анализом выявленных расхождений. В идеальном случае расхождений быть не должно. При наличии подобных расхождений необходимо провести оценку их влияния на потребительские свойства программного продукта. Анализ побочных эффектов системы защиты очень важен, так как в результате его проведения оценивается влияние защиты на конкурентоспособность продукта на рынке.
Доработка СЗПО (устранение побочных эффектов). В случае выявления побочных эффектов, оказывающих значительное влияние на функциональность и потребительские свойства ПО, необходимо выполнить доработку системы защиты, с целью ликвидировать или минимизировать указанные побочные эффекты. Примером негативного влияния СЗПО на качество программного продукта может служить снижение надёжности (повышение вероятности сбоя), повышение системных требований, конфликты с другими (прикладными или системными) программами, замедление работы ПО, необходимость особой настройки системы защиты и т.п. После доработки СЗПО тестирование на побочные эффекты повторяется.
Тестирование фактического уровня защиты, обеспечиваемого СЗПО. На данном этапе проводится тестирование фактического уровня защиты конкретного программного продукта. Фактически, здесь повторяются тесты, основанные на «диверсионном подходе», которые проводились для тестового защищаемого приложения. Результаты проведённых на этом этапе тестов определяют фактическую стойкость созданной СЗПО (применительно к данному продукту). На их основе можно оценить требуемую квалификацию злоумышленника и инструментарий, требуемые для преодоления системы защиты. Соответственно, у разработчиков появляется возможность оценить затраты времени и средств, которые злоумышленник должен будет понести, преодолевая защиту. Если по итогам тестов полученный уровень стойкости защиты соответствует спецификациям, разработку СЗПО можно считать завершённой.
Доработка СЗПО (повышение стойкости к атакам). Если уровень защиты не соответствует спецификациям, необходимо произвести доводку системы защиты с целью доведения её устойчивости к атакам до запланированного уровня. Примерами доработки СЗПО могут служить: шифрация текстовых сообщений системы защиты (по которым легко можно локализовать СЗПО), использование стойких криптоалгоритов для шифрования кода ПО, отказ от хранения эталонного пароля в теле программы, использование упаковки объектного кода, использование антиотладочных механизмов, затруднение дизассемблирования объектного кода и т.п. [2]. После доработки СЗПО должна быть вновь протестирована на предмет побочных эффектов.
Документирование и сопровождение СЗПО. Завершающим этапом процесса разработки СЗПО является окончательное оформление документации (разработка которой должна вестись на всех перечисленных этапах проектирования и реализации системы защиты) на разработанную систему и переход к сопровождению этой системы. В рамках сопровождения необходимо выполнять работы по внесению усовершенствований в разработанную СЗПО, расширению её функциональности, повышению стойкости и т.п. В результате будет получена корректно спроектированная и реализованная система программно-технической защиты программного обеспечения с заданными параметрами.
По нашему мнению разработка систем защиты программного обеспечения по приведённой схеме (с её упрощением или усложнением в зависимости от конкретной ситуации) позволит получать качественные, надёжные и устойчивые к атакам программные продукты, которые вкупе с законодательными и организационными «антипиратскими» мерами смогут успешно противостоять попыткам несанкционированного использования и распространения.
Литература:
| Наверх | Письмо Web-мастеру |
