Home

Автор: Полаженко Сергей, ведущий проекта «Тестирование безопасности»

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

Оглавление

• Введение
  
• Проблема защищённости и безопасности программных продуктов
  
• Основные категории субъектов, заинтересованных в разработке, эксплуатации и распространении программного продукта
  
• Источники проблем информационной безопасности программных продуктов
  
• Принципы безопасности и защищённости программных продуктов
  
• Категории объектов защиты программных продуктов
  
• Уровни представления программных продуктов с позиции информационной безопасности
  
• Вопросы обеспечения гарантий безопасности и защищённости программных продуктов
  
• Меры по обеспечению безопасности и защищённости ПП
  
• Заключение
  
• Список использованных источников
  

Введение

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

Приходиться признавать, что, например, системы Интернет-платежей для виртуальных магазинов, как правило, разрабатываются для каждого магазина отдельно, практически «с нуля», используя технические средства без учёта степени их защищённости. В результате не удивительным становится такое количество сообщений о различных видах Интернет-мошенничества [1]. Разработкой подобных критичных систем занимаются программисты, возможно прекрасно знающие языки и методы программирования, но не имеющие достаточных как практических, так и теоретических знаний в области информационной безопасности. У программистов нет времени для мониторинга новых уязвимостей используемых технологий, — у них есть задачи, и есть сроки для их выполнения.

Пример(переквалификация программистов)

В начале 2002 года работа более 8,5 тыс. разработчиков Microsoft оказалась под жестким контролем, поскольку в это время проводилась тщательная проверка миллионов строк кода Windows с точки зрения их безопасности. Все инженеры подразделения Windows и несколько тысяч инженеров из других подразделений проходили специальную программу обучения по созданию безопасного программного обеспечения. Планировалось, что такая остановка в работе продлиться 30 дней. Фактически она заняла в 2 раза больше времени и обошлась корпорации Microsoft в 100 млн. долл. [2]

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

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

Пример (утечка закрытых баз данных).

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

В марте 2005 года стало известно, что в руки компьютерных пиратов попала база данных по банковским проводкам с апреля 2003 г. по сентябрь 2004 г, которая содержит всю информацию по проводкам: реквизиты плательщика и получателя, их банков и назначение платежа [4].

Примечание. К сожалению, в вопросах регулирования отношений между разработчиками и пользователями ПП необходимо признать наличие большого числа «подводных камней». Например, как отмечается в [5], правовой статус баз персональных данных в РФ остаётся неопределенным. Наличие в Конституции РФ гарантии неприкосновенности частной жизни и принцип прямого действия самой Конституции правоохранительные органы, как правило, считают недостаточными для возбуждения уголовного дела. В результате — недостатки национального законодательства, а также отсутствие соответствующей судебной практики, пока не позволяют потребителям информационных технологий эффективно использовать законы и нормы права для защиты своих интересов [6]. Именно поэтому пользователи ПП предпочтут потратить дополнительные средства на покупку более защищённого и безопасного решения, нежели полагаться на защиту своих интересов в судах.

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

Пример (угроза потери доли рынка) .

В сентябре 2001-года John Pescatore , эксперт в области Интернет-безопасности компании Gartner, ведущей консалтинговой компании в области информационных технологий, рекомендовал компаниям и организациям, которые пострадали от вирусов Red Code и Nimda, немедленно отказаться от использования Microsoft Internet Information Server [7]. Подобные рекомендации не могли не сказаться на популярности Веб-серверов на рынке [8]. Следует признать, что последующие версии Веб-сервера компании Microsoft , выходили с возросшим вниманием к вопросам обеспечения информационной безопасности [9].

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

Пример(масштаб пиратского рынка).

В паре разработчик ПП — пользователь ПП зачастую наиболее уязвимым является именно разработчик ПП. Так по данным компании IDC в 2004-ом году [10] в среднем доля пиратского программного обеспечения в глобальном масштабе составляет 36%, то есть, грубо говоря, каждые четыре из десяти копий программы оказываются в каком-то смысле украденными у производителя и лишают его прибыли. Торгово-промышленная палата РФ в 2002-ом году отмечает [11], что в среднем на каждой третьей машине в РФ установлено нелицензионного программного обеспечения более чем на 1000 у.е.

Такая беззащитность производителя ПП не удивительна. Злоумышленники («пираты») имеют более выгодное положение в том смысле что, обладая копией ПП (возможно ограниченной demo или evaluation версией), защиту которого они собираются взломать, — они без ограничений могут применять самые различные средства и методы анализа алгоритмов и механизмов защиты ПП. В данном случае ПП находится под полным контролем злоумышленников: все обращения ПП к файлам данных, к сетевым интерфейсам, а также к произвольным функциям системных библиотек ОС могут быть обнаружены, идентифицированы и запротоколированы различными средствами мониторинга активности процессов операционной системы. Сама программа может быть дизассемблирована или же запущена под отладчиком и т.д. Злоумышленники могут анализировать не только сами файлы ПП, но также логику работы программы, состояние оперативной памяти ПП во время его работы и т.д. Достаточно полный обзор методов и средств «взлома» компьютерных программ может быть найден в работе [12].

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

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

[ Содержание ]

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

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

Программный продукт — множество компьютерных программ, процедур вместе с соответствующей документацией и данными (Международный стандарт ISO / IEC 14598-1-6:1998-2001 «Software engineering — Product evaluation» ).

Программа — данные, предназначенные для управления конкретными компонентами системы обработки информации в целях реализации определенного алгоритма (ГОСТ 19781-90 «Программное обеспечение систем обработки информации. Термины и определения»).

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

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

[ Содержание ]

Основные категории субъектов, заинтересованных в разработке, эксплуатации и распространении программного продукта

Рассмотрим следующие категории лиц:

• разработчики ПП;
• пользователи ПП (авторизованные и неавторизованные);
• прочие лица;

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

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

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

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

[ Содержание ]

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

Источниками проблем информационной безопасности в программных продуктах могут быть названы:

1. Конфликт интересов между разработчиком ПП и его пользователями.

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

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

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

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

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

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

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

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

[ Содержание ]

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

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

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

[ Содержание ]

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

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

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

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

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

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

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

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

[ Содержание ]

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

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

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

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

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

[ Содержание ]

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

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

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

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

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

Рис. 1 – Зависимость прибыли разработчика от степени защищённости ПП
(иллюстрация из статьи [16] , приводится с согласия авторов)

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

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

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

[ Содержание ]

Меры по обеспечению безопасности и защищённости ПП

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

а) для защиты интересов потребителей от угроз со стороны разработчика ПП — независимая компетентная экспертиза (тестирование) безопасности и защищённости решений разработчика;

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

В качестве независимой экспертизы может применяться процедура добровольной аттестации объектов информатизации по требованиям безопасности информации (см. « Положение по аттестации объектов информатизации по требованиям безопасности информации»), которую в соответствии с положением проводит Гостехкомиссия России. Так же в сети Интернет можно найти примеры использования услуг коммерческих организаций.

Будущее вопросов независимой аттестации объектов информатизации связывают с новым стандартом ГОСТ Р ИСО/МЭК 15408-1-3 «Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий» (национальная версия международного стандарта ISO/ IEC 15408, общеизвестного под названием "Common criteria"). В РФ сделаны серьезные шаги по практическому применению этих стандартов, на пример, — сертификация продуктов компании Microsoft [18].

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

[ Содержание ]

Заключение

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

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

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

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

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

[ Содержание ]

Список использованных источников

1. Голдовский И., Безопасность платежей в Интернете
   
2. Письмо Билла Гейтса о новых взглядах Microsoft на вопросы обеспечения информационной безопасности
   
3. Смирнов С., "Краденое — со скидкой", портал "Права человека в России", 28 февраля 2003 г.
4. Банковской тайны в России больше не существует.
   
5. Смирнов С., Кочева О., Приватность в российском Интернете
   
6. Середа С., О необходимости защиты прав потребителя в сфере информационных технологий.
   
7. Gartner Recommends Against Microsoft IIS
   
8. Web Server Survey
   
9. Follow-up on IIS6 and Apache Security (part 1, part 2)
10. Результаты исследования опубликованы на веб-узле BSA по адресу www.bsa.org/idcstudy . Информацию об исследовании на русском языке можно найти в бюллетене Представительства Microsoft в России и СНГ «Влияние уровня компьютерного пиратства на развитие мировой экономики. По материалам исследования компании IDC», специальный выпуск, 2003 г.
11. Пиратство в России. Итоги "круглого стола"
    
12. CyberManiac, Теоретические основы крэкинга.
13. Полаженко С., Вариант определения понятий защищённости и безопасности программных продуктов
    
14. Середа С., Программно-аппаратные системы защиты программного обеспечения
    
15. Компьютерная преступность и информационная безопасность / Под общ. ред. А.П. Леонова. — Мн.: АРИЛ, 2000. — 552 с.— (Библиотека журнала «Управление защитой информации»).
16. Новичков А., Сардарян Р. Анализ рынка средств защиты от копирования и взлома программных средств
    
17. Конкурс компании Microsoft на лучшее литературное произведение о честно купленном программном обеспечении.
    
18. Сергеева Н., Сертификация продуктов Microsoft в России
    

[ Содержание ]