Файл: Учебник для вузов В. Г. Олифер, Н. А. Олифер 2е изд. Спб. Питер 2009 669 с ил. Межсетевое экранирование учеб пособие О. Р. Лапонина М. Интернет Ун т Информ. Технологий бином. Лаб знаний 2007 343 с ил.pdf

39
рисков информационной безопасности на приемлемом уровне. Если риск не изменился и защитные меры внедрены и хорошо работают, значит риски снижены достаточно.
Продолжение анализа уязвимостей и выявления нуждающихся в защите активов также является важной задачей управления рисками.
5.11. Общий риск и Остаточный риск
Общий риск (total risk)- это риск, перед лицом которого стоит компания, не внедрившая никаких защитных мер. Если его уровень не приемлем для компании
(вероятный ущерб от реализации риска превышает стоимость защитных мер), она внедряет защитные меры чтобы снизить общий риск до приемлемого уровня. Однако систем или сред, защищенных на 100%, не существует - всегда есть некоторый остаточный риск (residual risk). Необходимо обеспечить, чтобы уровень остаточного риска был приемлем для компании.

40
цели связаны с производством компанией готовой продукции и выводом ее на рынок, а вовсе не с рисками.
Они не хотят увязать в этой глупой, непонятной и раздражающей безопасности...
Принятие риска должно быть основано на нескольких факторах. В частности, нужно ответить на следующие вопросы. Потенциальные потери меньше стоимости контрмер? Сможет ли компания жить с теми потерями, которые причинит ей принятие этого риска?
Второй вопрос имеет отношение, в том числе и к бесплатным решениям.
Например, если компания примет этот риск, она должна будет добавить еще три шага в свой производственный процесс. Имеет ли это смысл для нее? В другом случае, принятие риска может привести к возрастанию количества инцидентов безопасности – готовы ли компания справиться с этим?
Человек или группа, принимающая риск, должны понимать потенциальные последствия этого решения. Предположим, было установлено, что компания не нуждается в защите имен клиентов, но она должна защищать другие сведения, такие как номера социального страхования, номера счетов и т.д. При этом ее деятельность останется в рамках действующего законодательства. Но что будет, если ее клиенты узнают что компания не защищает должным образом их имена? Ведь они из-за отсутствия знаний по этому вопросу могут подумать, что это может стать причиной «кражи личности», что приведет к серьезному удару по репутации компании, с которым она может и не справиться.
Восприятие клиентов часто не обосновано, и всегда существует вероятность, что они перенесут свой бизнес в другую компанию, и вам нужно считаться с этой потенциальной возможностью.
Рис. 8 показывает, как может быть создана программа управления рисками, которая объединяет все понятия, описанные в настоящем разделе.

41
Рис. 8. - Вариант программы управления рисками
6. Персонал
Многие обязанности персонала имеют прямое отношение к безопасности компании. Хотя общество стало чрезвычайно зависимым от технологий, люди остаются ключевым фактором успеха компании. В безопасности чаще всего именно человек является слабейшим звеном. Это является следствием человеческих ошибок, недостатков в обучении и приводит к мошенничеству, несанкционированным или небезопасным действиям. Человек во многих случаях является причиной успеха хакерских атак, шпионажа, повреждения оборудования. Хотя будущие действия людей нельзя предсказать, можно внедрить определенные превентивные меры, которые помогут минимизировать риски. Такими превентивными мерами могут быть следующие: прием на работу только квалифицированного персонала, контрольные мероприятия, детальные должностные инструкции, обучение персонала, строгий контроль доступа, обеспечение безопасности при увольнении сотрудников.
6.1. Структура
Если компания хочет иметь эффективную безопасность на уровне персонала, руководство должно внедрить четкую структуру и следовать ей. Эта структура включает в себя четкое

42
описание обязанностей, разграничение полномочий, ответственность (например, объявление выговоров) за определенные действия. Четкая структура исключает непонимание, кто и что должен делать в различных ситуациях.
Есть несколько аспектов, которые должны быть внедрены для снижения возможностей для мошенничества, саботажа, краж, неправильного использования информации, а также уменьшения вероятности возникновения других проблем безопасности. Одним из таких аспектов является разделение обязанностей (separation of duties), которое гарантирует, что один человек не сможет самостоятельно выполнить критичную задачу. Разделение обязанностей также снижает вероятность ошибок – если один человек ошибся, другой, скорее всего, увидит ее и исправит. Разделение обязанностей снижает риски мошенничества, так как сотрудник не может выполнить самостоятельно критичную операцию и ему необходимо вступить в сговор с другим сотрудником, а вероятность сговора двух и более людей существенно ниже вероятности действий отдельного человека.
При разработке программного обеспечения должно быть явное разделение между средой разработки, средой тестирования, библиотекой программного обеспечения и производственной средой. Программистам должна быть доступна только среда разработки, в которой они могут разрабатывать программное обеспечение и производить его предварительное тестирование. После разработки исходные тексты передаются другому человеку, который проводит контроль качества кода и тестирование его работы в отдельной среде, являющейся копией производственной среды. Только когда код прошел все необходимые тесты, он размещается в библиотеке программного обеспечения. Для внедрения в производственную среду, программное обеспечение берется только из библиотеки. Код ни в коем случае не должен попадать напрямую от программиста в производственную среду без тестирования и сохранения в библиотеке! Тестовая среда должна быть полностью отделена от производственной, чтобы непроверенное еще программное обеспечение не нанесло вреда данным и системам, находящимся в реальной работе. Программист не должен «латать» свои программы непосредственно в процессе их эксплуатации! Должны быть внедрены простые и эффективные методы, не позволяющие вносить изменения в программное обеспечение компании небезопасными способами.
7. Выводы
Программа безопасности должна учитывать вопросы со стратегической, тактической и оперативной точки зрения, как показано на рис. 9. Управление безопасностью включает в себя административные и процедурные мероприятия, необходимые для поддержки и защиты информации, а также активов в рамках компании в целом. Кроме того, управление безопасностью включает в себя разработку и внедрение политик безопасности и их вспомогательных механизмов: процедур, стандартов, базисов и руководств. Также, оно включает в себя управление рисками, обучение по вопросам безопасности, выбор и внедрение эффективных контрмер. Деятельность, связанная с персоналом (прием на работу, увольнение, обучение и структура управления) и его функциями (ротация и разделение обязанностей), должна проводиться надлежащим образом в целях создания безопасных условий. Руководство должно уважать и соблюдать необходимые правовые и этические нормы.
Безопасность – это задача бизнеса, она должна рассматриваться именно в этом качестве.
Она должна быть интегрирована в бизнес-цели и задачи компании, так как вопросы безопасности могут негативно сказаться на тех ресурсах, от которых зависит компания.
Все большее и большее количество компаний, не уделявших должного внимания, поддержки и финансирования безопасности, несут колоссальные убытки. Хотя мы живем в прекрасном и удивительном мире, в нем может случиться всякое. Те, кто понимает это, могут не только выживать, но и процветать.

43
Рис. 9 – Компоненты программы безопасности.

44 8. Основы обеспечения информационной безопасности компьютерных систем.
Программные и аппаратные механизмы защиты
Многие механизмы защиты могут быть реализованы как на программном, так и на аппаратном уровне, однако более стойкими считаются аппаратные реализации. Это связано со следующими причинами:
Целостность программной защиты легко нарушить, это дает возможность злоумышленнику изменить алгоритм функционирования защиты необходимым образом, например, заставить процедуру контроля электронно-цифровой подписи всегда выдавать верные результаты. Нарушить целостность аппаратных реализаций зачастую невозможно в принципе в силу технологии их производства.
Стоимость аппаратных средств защиты во многом повышается благодаря сокрытию защитных механизмов на аппаратном уровне, злоумышленник при этом не может их исследовать в отличие от программной защиты.
9. Защита от изменения и контроль целостности программного обеспечения
9.1. Защита программного обеспечения от несанкционированного использования
Включает в себя:
1. Организационно-правовые меры.
2. Правовые меры (распространение на программное обеспечение авторского права).
3. Технические меры.
9.2. Модульная архитектура технических средств защиты ПО от несанкционированного копирования
Особенностью всех технических мер защиты является то, xто их реализация построена на выделении, либо принудительном введении каких – либо идентифицирующих элементов в среде функционирования программы, на которые настраивается система защиты. В качестве таких характеристик среды может быть использованы серийный номер, ключевой файл, информация в реестре, в конфигурации файлов, конфигурация аппаратуры, физический дефект носителей информации.
Основные требования к системе защиты ПО от несанкционированного копирования:
1. такая система должна достоверно выявлять факт несанкционированного использования программы
2. реагировать на факт несанкционированного использования
3. противодействовать возможным атакам, направленным на нейтрализацию защитных механизмов

45
Рис. 10 – Структура системы защиты ПО
Система защиты ПО от несанкционированного копирования работает по следующему алгоритму:
1. разработчик
ПО разрабатывает и внедряет защитные механизмы в исполнительную программу
2. в эти защитные механизмы закладываются эталонные характеристики среды, которые идентифицируют конкретную копию программы и относительно которой будет проверяться легальность запуска
3. при каждом запуске программы выполняются следующие действия: снимают текущие характеристики среды, они сравниваются с эталонными. Если сравнение дало положительный результат, то запуск программы считается санкционированным. Программа запуска продолжает работать. Если сравнение дало отрицательный результат, то запускается блок ответной реакции.
За установку текущих характеристик среды отвечает блок ответной реакции. Выход этого блока поступает на блок сравнения характеристик среды, который сравнивает текущие характеристики среды с эталонными.
По способу внедрения защитного кода в защищаемую программу различают встроенную и пристыковочную защиты.
Встроенные механизмы защиты основываются на том, что система как самостоятельный программный модуль отсутствует. Эти механизмы защиты внедряет сам разработчик в исходный текст программы, используя, например набор готовых API- функций защиты.
Преимущества:
1. Простота. С помощью библиотек и функций, поставляется совместно с ПА средствами защиты, от ПА средства можно добиться максимальной эффективности
2. при реализации встроенной защиты, разработчик может запрограммировать любую ответную реакцию программы на несовпадение характеристик с эталонными, что в свою очередь позволяет более хорошо реализовать маркетинговые функции. Например,

46
при отсутствии электронного ключа, может запускать программу в демонстрационном режиме.
3. защита производится не по детерминированному алгоритму. Разработчик сам определяет, когда и каким образом будут вызываться API-функции с ПА устройствами защиты, как будут обрабатываться возвращаемые ими результаты.
Недостаток: сложная реализация.
Модуль противодействия нейтрализации защитных механизмов затрудняет анализ злоумышленником защитного кода, противодействует вмешательству в его работу и выполняется по 2 направлениям:
1) статическое
2) динамическое
При статической нейтрализации злоумышленник дизассемблирует программу с помощью таких средств, как Ida Pro, по полученному коду, разбирается с работой механизмов, как их грамотно отключить.
При динамической нейтрализации вмешательство в работу программы производится в момент работы в реальном времени с помощью существующих средств отладки, например, Soft Ice.
Пристыковочные механизмы защиты внедряются непосредственно в исполнительный код, реализуется непосредственно некого автоматического обработчика исполнительных файлов. Эти обработчики заключают исполнительный код программы в некую защитную оболочку, которой при старте программы передается управление. При старте программы запускается защитная оболочка, реализующая все защитные функции, проверки, по результатам которых принимается решение о запуске/незапуске программы. Они поставляются в виде неких wizad-ов. При использовании подобных wizard-ов от пользователя требуется минимум действий, например, указать программу, требующую защиту и способ защиты.
9.3. Защита программного обеспечения от исследования
Исследование исполняемого кода программы позволяет злоумышленнику разобраться с логикой работы защитных механизмов, что дает возможность отключить их либо обойти. При работе с аппаратными средствами защиты в исполняемом коде программы достаточно часто хранится конфиденциальная информация, например, коды доступа к электронному ключу, который не должен знать злоумышленник. Иначе говоря, возможность исследования кода является необходимым условием взлома программных продуктов. В связи с этим исполняемый код необходимо защищать от исследования. Для защиты ПО от исследования необходимо обеспечить защиту от статического и динамического анализа.
В первом случае злоумышленник пытается получить листинг программы на каком- либо языке для возможности дальнейшего изучения и исследования логики защитных механизмов с использованием таких средств как Ida Pro, Soucer.
Большая часть средств защиты от отладки основывается на обнаружении отладчиков в оперативной памяти с целью дальнейшего противодействия отладке, либо на включенных в исполняемый код механизмов, которые не могут быть корректно выполнены под отладкой в режиме трассировки.
9.4. Классификация средств атаки на средства защиты программного обеспечения