Основы безопасности программного обеспечения

Размещено на http://www.allbest.ru/

\

Оглавление

• 1. Введение в курсовой проект
• 2. Введение в теоретическую часть
• 3. Безопасная инфраструктура
• 4. Создание безопасных сетей для поддержки приложений
• 4.1 Настройка сети
• 5. Настройка безопасных узлов для приложений
• 5.1 Работа с исправлениями
• 5.2 Настройка
• 5.3 Разрешения
• 5.4 Общие строки протокола SNMP
• 5.5 Антивирусные программы
• 5.6 Серверы: аудит и ведение журналов
• 6. Уровень приложений: требования
• 6.1 Проверка данных ввода
• 6.2 Управление сеансами
• 6.3 Проверка подлинности и авторизация
• 6.4 Проверка конструкции и программного кода приложения
• 6.5 Обработка ошибок на уровне сервера и приложения
• 6.6 Приложения: аудит и ведение журналов
• 6.7 Архивация и восстановление приложений
• 6.8 Шифрование личных данных
• 7. Общие вопросы разработки приложений
• 7.1 Проверка данных пользовательского ввода
• 7.2 Пароли
• 7.3 Таблицы управления доступом
• 8. Практическая часть
• 9. Список использованной литературы
• 1. Введение в курсовой проект
• протокол несанкционированный доступ шифрование архивация
• Сейчас выпущена и выпускается огромная масса программных продуктов, которые так или иначе подвергаются атакам хакеров и злоумышленников.
• Хакеры взламывают программы не только в личных целях, но и в связи с нынешней философией хакерского дела, для бесплатного распространения по сети интернет. Но остаются и те кто просто пытается навредить пользователям программ.
• В связи с этим можно выдвинуть три более важных аспекта защиты программных продуктов:
• Защита авторских прав.
• Защита работоспособности ПО.
• Защита информации.
• О способах защиты мы и поговорим в данной работе.
• В практической части работы рассматривается некая компания в которой надо создать ведомость по заработной плате с установленными меж табличными связями.
• Для решения данной задачи использовался ПК со следующими характеристиками:
• Процессор AMD 64 3000+
• ОЗУ DDR2 512 Mb
• Видеокарта GeForce 6200
• Жесткий диск 250 Гб SATA-2
• Монитор Acer C500
• Программное обеспечение:
• Windows Xp Pro SP3
• MS Office (Word, Excel)
• Nero v8
• 2. Введение в теоретическую часть
• Многие пользователи считают, что антивирусная защита на уровне содержимого файл-серверов и рабочих станций решает все проблемы, однако это далеко не так.
• Здесь надо уточнить, что рассматривается процесс обработки информации в достаточно территориально развитой локальной сети, рабочие станции которой удалены друг от друга, и администратор физически не сможет их быстро обойти. Для эффективной работы такой системы необходимы централизованное управление антивирусной защитой, делегирование полномочий, автоматизация аварийных извещений, создание групп безопасности и т.п.
• Конечно, настраивать и эксплуатировать средства защиты сетевых приложений следует с учетом назначения, функционирования и архитектуры конкретного приложения. Однако при этом нельзя забывать об общем свойстве всех сетевых приложений - концентрации обработки данных в одном месте сети и передаче результатов обработки во многие ее точки.
• При этом нельзя забывать о многих нюансах защиты самих приложений и правильной настройке рабочих станций.
• 3. Безопасная инфраструктура
• Для безопасности приложений необходима безопасная инфрастуктура. Уязвимость на уровне сети и узлов может подорвать безопасность приложений и их данных. Инфраструктура разделяется на пять основных архитектурных компонентов:
• · сеть;
• · узел;
• · приложение;
• · учетная запись;
• · доверие. [1. стр. 38]
• Для каждой из этих областей характерны свои уязвимые места, которые необходимо отслеживать.
• Чтобы минимизировать риск нарушения безопасности, необходимо реализовать детальную стратегию защиты среды, в которой выполняются приложения, от внутренних и внешних угроз. Данная стратегия, получившая название всесторонняя защита (defense in depth или security in depth), предполагает выстраивание уровней контрмер вокруг уязвимых областей. Она предусматривает внедрение мер защиты на каждом уровне инфраструктуры приложений, от внешних маршрутизаторов до места физического размещения ресурсов, включая все промежуточные пункты. Реализация нескольких уровней безопасности позволяет исключить зависимость приложений и ресурсов от отдельного сбоя.
• Контрмеры, используемые для обеспечения безопасности, могут иметь множество форм: письменное изложение правил соблюдения безопасности, параметры настройки инфраструктуры, мониторинг приложений и обнаружение атак.
• 4. Создание безопасных сетей для поддержки приложений
• Первым шагом на пути защиты приложения является обеспечение безопасности сети, в которой оно выполняется.
• 4.1 Настройка сети
• Правильная настройка сети позволяет свести к минимуму уязвимость серверов и баз данных, содержащих информацию, которую требуется изолировать.
• Топология сети организации должна быть проанализирована с точки зрения сетевой безопасности:
• Сегментация сети минимизирует "неявные" доверительные отношения между серверами, нередко используемые при проведении атак.
• Сегментация сети путем настройки виртуальной локальной сети позволяет разделить серверы в организации в соответствии с их ролями, а также уровнем важности хранящихся на них данных.
• · Для установки брандмауэров подразделение информационных технологий дает следующие рекомендации:
• · Брандмауэры должны максимально ограничивать число открытых портов для входящего и исходящего трафика - как для внутренних, так и для внешних сетей.
• · Необходимо регулярно проводить аудит конфигурации брандмауэра, чтобы предотвратить раскрытие дополнительных служб и серверов при обновлении параметров брандмауэра.
• · Для каждого брандмауэра должен применяться собственный пароль либо другой механизм контроля доступа. Это позволяет предотвратить применение одного и того же механизма для взлома нескольких брандмауэров.
• · Права на изменение функций, параметров подключения и служб, поддерживаемых брандмауэрами, должны принадлежать лишь нескольким доверенным и технически подготовленным сотрудникам, которым эти права необходимы для выполнения своих служебных обязанностей.
• · На серверах брандмауэров должны быть установлены и включены лишь самые необходимые компоненты операционной системы. Брандмауэр уровня приложений с функциями proxy-сервера, например Microsoft Internet Security and Acceleration (ISA) Server, является более эффективным решением, чем простой брандмауэр, выполняющий фильтрацию пакетов. Сервер ISA позволяет реализовывать дополнительные правила, допускающие использование только определенных коммуникационных запросов и протоколов. [1. стр. 54.]
• Для настройки и эксплуатации маршрутизаторов и коммутаторов подразделение информационных технологий дает следующие рекомендации:
• · Пароль доступа к административному режиму (Enable Password) для маршрутизатора должен храниться в безопасном зашифрованном виде.
• · Только оператору сети и группам разработки, ответственным за создание, установку и настройку сетевых устройств, должно быть предоставлено право производить установку и удаление устройств, осуществлять техническую поддержку оборудования и изменять физическую конфигурацию маршрутизатора.
• · Маршрутизаторы должны регистрировать все изменения конфигурации с указанием времени, даты и сведений о пользователе, выполняющем изменения.
• · Журналы маршрутизатора должны направляться на узел журналов - выделенный компьютер в защищенной или доверенной сети, единственной функцией которого является хранение журналов.
• · Необходимо обезопасить узел журналов, удалив с него все ненужные службы и учетные записи.
• · Просмотр журналов для обнаружения признаков несанкционированного доступа должен выполняться регулярно. Данная обязанность должна лежать на группе операторов сети, ответственной за сопровождение маршрутизаторов.
• · Таблицы маршрутизаторов необходимо защитить от несанкционированного доступа и использовать только внутри организации. Изменение злоумышленником записей в этих таблицах может привести к снижению быстродействия, отказу служб связи и раскрытию важных данных.
• · Если в каких-либо службах, портах и протоколах нет явной потребности, они должны быть отключены.
• · Администрирование маршрутизатора должно осуществляться исключительно в локальной сети, а не в удаленном режиме (из глобальной сети или по коммутируемому соединению). [2.]
• 5. Настройка безопасных узлов для приложений
• Не менее важное значение для реализации безопасной сети имеет безопасность компьютеров, на которых выполняются приложения.
• 5.1 Работа с исправлениями
• На серверы должны регулярно устанавливаться новейшие исправления безопасности по мере их выпуска (включая исправления всех производителей, чье программное обеспечение выполняется на сервере). Сотрудникам технической службы следует регулярно посещать веб-узлы производителей ПО, а также независимые узлы, на которых публикуется информация об обнаруженных ошибках, для получения последних новостей и новейших исправлений.
• 5.2 Настройка
• Серверы и установленные на них программные продукты должны быть настроены в точном соответствии с инструкциями по обеспечению безопасности, предоставленными соответствующим поставщиком. Любые службы, которые не требуются для работы приложения, необходимо отключить и блокировать, а не выполнять с параметрами по умолчанию.
• Ненужные расширения файлов не следует назначать на веб-серверах, поскольку это может привести к атакам с применением неизвестных уязвимостей.
• 5.3 Разрешения
• Параметры ACL-разрешений должны быть правильно настроены для всех общих ресурсов и других элементов системы и баз данных, а также объектов COM+ в целях предотвращения несанкционированного доступа.
• 5.4 Общие строки протокола SNMP
• Общие строки (community strings) протокола SNMP⁴ применяются для контроля доступа к объектам MIB⁵; они функционируют как встроенные пароли сетевого оборудования. К общим строкам SNMP применимы правила задания, хранения и периодической смены, используемые для надежных паролей. Если нет явной необходимости в использовании SNMP, следует удалить общую строку и отключить службу SNMP. Не следует забывать, что почти все устройства поставляются с используемым по умолчанию SNMP-паролем (public). [2.]
• 5.5 Антивирусные программы
• На всех серверах независимо от их назначения должны выполняться антивирусные программы, активно сканирующие все области системы и все общие каталоги. Подразделение информационных технологий практикует трехуровневый подход к защите от вирусов в масштабе всей организации:
• автоматическая проверка настольных компьютеров при входе пользователя в систему для подтверждения того, что в организации установлена самая последняя версия антивирусной программы и имеется полный список всех обнаруженных к данному моменту вирусов;
• сканирование трафика на всех каналах передачи сообщений;
• выполнение антивирусных программ на всех серверах сети и автоматическое обновление списка всех существующих вирусов.
• 5.6 Серверы: аудит и ведение журналов
• Аудит и ведение журналов имеют важное значение для обнаружения атак и обеспечения целостности данных. Аудит помогает администраторам и лицам, ответственным за решение проблем в области безопасности, анализировать предпринятые атаки и решать другие задачи. Он также защищает пользователей от возможных подозрений, связанных с незаконным использованием компьютеров или преступлениями в области информационных технологий.
• 6. Уровень приложений: требования
• После обеспечения надлежащей защиты сети и хост-сервера необходимо позаботиться о безопасности самих приложений.
• 6.1 Проверка данных ввода
• Проверка данных, вводимых пользователями, должна выполняться программным способом внутри кода приложения. Необходимо выполнять проверку использования специальных символов, числовых значений вне ожидаемого диапазона, длины строк, возможных вложений программного кода⁶ , а также длины содержимого для загружаемых файлов. Более подробная информация о проверке данных ввода приводится далее в этой статье в разделе "Общие вопросы разработки приложений".
• 6.2 Управление сеансами
• Коды сеансов⁷ должны быть произвольными и иметь достаточную длину для предотвращения взлома методом грубой силы. Информация о сеансах должна храниться на сервере, а не на клиентском компьютере. Если приложение хранит данные сеанса в виде простого текста в файлах cookie на клиентском ПК, злонамеренный пользователь сможет легко изменить данные сеанса и получить доступ к информации незаконным способом. Этот метод может быть также использован для получения разрешений более высокого уровня, например разрешения администратора. Сеансы должны закрываться по истечении времени ожидания после установленного периода бездействия или при выходе пользователя. Поскольку коды сеансов могут быть похищены и использованы повторно, не следует применять сеансы для кэширования данных проверки подлинности пользователя. Дополнительная информация о кодах сеансов и файлах cookie приводится далее в этой статье в разделе "Общие вопросы разработки приложений".
• 6.3 Проверка подлинности и авторизация
• Некорректные методы проверки подлинности и авторизации могут стать причиной незаконного доступа к приложению. Приложение должно обеспечивать безопасное управление проверкой подлинности. Маркеры авторизации (authorization token) должны быть достаточно надежны, чтобы их нельзя было угадать, и должны надлежащим образом проверяться на сервере.
• · Исходный код приложений должен быть защищен для предотвращения доступа неавторизованных пользователей. Если проверка подлинности не подтверждается, в доступе должно быть отказано.
• · Если в работе модулей контроля доступа возникли неполадки, поддерживаемые ими системы и приложения должны оставаться недоступными вплоть до устранения неисправности.
• · Во всех системах контроля доступа должны применяться уникальные идентификаторы и пароли для каждого пользователя. Следует запретить использование общих паролей.
• 6.4 Проверка конструкции и программного кода приложения
• Для обеспечения безопасной архитектуры и методов разработки необходимо перед написанием программного кода проводить формальную проверку создаваемого приложения на безопасность конструкции. Такая проверка должна, как минимум, включать все элементы, перечисленные в настоящей статье. После написания программного кода следует выполнить предварительную оцен-ку безопасности, подтверждающую, что все недостатки, выявленные на этапе проверки конструкции, устранены и приложение отвечает требованиям безопасности. Для выявления известных уязвимостей необходимо выполнить проверку с помощью сканеров безопасности в среде тестирования. Должны быть произведены проверки для обнаружения атак с вложением программного кода, атак типа cross-site scripting, атак с отказом в обслуживании, переполнением буфера и т. д. Кроме того, группа разработки приложения должна регулярно выполнять проверку программного кода для выявления подобных проблем. [1. стр. 76]
• 6.5 Обработка ошибок на уровне сервера и приложения
• Процедуры обработки ошибок не должны раскрывать имена серверов, пути к общим ресурсам, имена файлов или таблиц баз данных. Ошибки должны распознаваться в момент их появления и обрабатываться без аварийного сбоя в приложении. Программный код должен обеспечивать возможность восстановления в случае некритических ошибок (например, повторные попытки по истечении времени ожидания) и нормальный выход с регистрацией подробных сведений об ошибке.
• Сбой в любой точке приложения не должен приводить к нарушению безопасности. Все переменные управления, относящиеся к безопасности, должны приводиться к наиболее безопасному состоянию при инициализации, а при ненормальном завершении приложения должен выполняться нормальный выход с удалением всех не подлежащих разглашению данных и блокировкой кода сеанса. Это позволяет предотвратить использование ошибки злонамеренным пользователем или программой.
• 6.6 Приложения: аудит и ведение журналов
• Приложения должны собирать информацию об успешных и неудачных попытках входа, а также других важных действиях, относящихся к безопасности. Ведение журналов также помогает при отладке; не имея возможности изучить данные, хранящиеся в журнале, разработчик вынужден строить предположения относительно того, почему пользователю было отказано в доступе к ресурсу.
• 6.7 Архивация и восстановление приложений
• Рекомендации в разделе "Архивация и восстановление сервера" также относятся и к приложениям. Кроме того, необходимо архивировать весь исходный код приложений. Чтобы предотвратить незаконное раскрытие или использование не подлежащих разглашению данных, всю конфиденциальную информацию, записанную на архивных носителях (магнитных лентах, гибких и оптических дисках и т. д.) и хранящуюся вне организации, следует держать в зашифрованной форме.
• 6.8 Шифрование личных данных
• Все личные данные (имена, пароли, сведения, позволяющие идентифицировать пользователя, информация о кредитных картах, даты рождения и т. д.) должны шифроваться с использованием надежного шифрования на основе отраслевых стандартов, например 3DES (Triple Data Encryption Standard). Информация этого типа не должна храниться в виде простого текста в каких-либо базах данных или файлах, независимо от того, насколько хорошо они защищены. [2.]
• 7. Общие вопросы разработки приложений
• Безопасность приложений должна обеспечиваться с самого начала процесса разработки. Помимо оценки создаваемого кода, разработчики приложений должны решать множество различных проблем. Безопасность сети, в которой будет выполняться приложение, безопасность серверной платформы, правильность данных ввода, получаемых от конечных пользователей, - все эти вопросы должны учитываться разработчиками при обеспечении безопасности приложений.
• Выполняя оценку безопасности внутренних приложений, подразделение информационных технологий обычно получает представление о проблемах, относящихся к разработке. Заранее устранив выявленные таким образом проблемы, разработчики могут повысить безопасность своих продуктов и содержащихся в них данных.
• 7.1 Проверка данных пользовательского ввода
• На основании опыта, полученного подразделением информационных технологий, проверка данных ввода поль-зователя должна выполняться во всех случаях, поскольку уровень риска уязвимости оценивается как высокий.
• Следует считать входящие данные недействительными, пока не будет доказано обратное, даже если приложение предполагает, что все запросы действительны. Чем быстрее приложение распознает недопустимый запрос, тем меньше опасность ущерба от выполнения злонамеренного кода. Злоумышленники учитывают то, что медленное распознавание недопустимых запросов в системе влияет на обработку законных запросов, снижая производительность сервера. Это наиболее распространенный пример проведения атак с отказом в обслуживании.
• Длительные и ресурсоемкие операции требуют такого же уровня безопасности, как и личные данные. Перед выполнением длинного SQL-запроса или операции, требующей значительных вычислительных ресурсов, необходимо сначала подтвердить законность запроса. Проверка подлинности веб-страницы, с которой поступает запрос, не только предотвращает расходование ресурсов сервера приложений злонамеренными пользователями, но и позволяет отслеживать события в журналах аудита, благодаря чему администраторы могут определить конкретного нарушителя.
• 7.2 Пароли
• Согласно политике отдела информационных технологий приложения в корпоративной сети должны использовать встроенную в Windows проверку подлинности. Если подлинность не подтверждается, то доступ к внутренним приложениям и данным автоматически блокируется.
• Соблюдение политик в отношении паролей требуется во всех случаях. Уровень риска, связанный с использованием ненадежных паролей, оценивается как высокий. Угадывание пароля - распространенный и нередко эффективный способ незаконного доступа к системам. Преодолев брандмауэр и попав на целевой компьютер, злоумышленники могут применить широко доступные средства эксплуатации уязвимостей для получения доступа в корневой каталог или прав администратора.
• 7.3 Таблицы управления доступом
• Некорректная настройка таблиц управления доступом (ACL) может привести к тому, что пользователи получат непредназначенные для них разрешения для доступа к системным ресурсам и данным, в результате чего может быть раскрыта секретная информация, нарушена доступность или целостность системы. Всегда следует задавать минимальный уровень полномочий, необходимый для выполнения конкретной операции. Для предотвращения несанкционированного доступа следует правильно настраивать таблицы ACL для общих ресурсов и временных каталогов, создаваемых приложениями.

1. Запустить табличный процессор MS Exсel.

2. Создать книгу с именем "Интернет".

3. Лист первый переименовать в "Тарифы".

4. Лист второй переименовать в "Курс".

5. Лист третий переименовываем в "Начисления".

6. На рабочем листе "Тарифы" формируем таблицу "Тарифы на услуги предоставления доступа к интернету для абонентов квартирного района".

Рис. 1. Тарифы на услуги

7. На листе "Курс" создаём таблицу "Курс у.е. к рублю РФ, установленный ООО "Сигмаком"".

Рис. 2. Курс у.е. к рублю РФ, установленный ООО "Сигмаком"

8. На листе "Начисления" создадим таблицу "Начисления за услуги предоставления доступа к интернету"

Рис. 3. Начисления за услуги предоставления доступа к интернету

9. Для заполнения таблицы "Начисления за услуги предоставления доступа к интернету" будем использовать функцию =ВПР(). Для этого на листе "Начисления" в ячёйку F4 поместим формулу =(E4-ВПР(B4;Тарифы!$A$4:$D$7;3;ИСТИНА))*(ВПР(B4;Тарифы!$A$4:$D$7;4;ИСТИНА))+ВПР(B4;Тарифы!$A$4:$D$7;2;ИСТИНА). ВПР(B4;Тарифы!$A$4:$D$7;3;ИСТИНА) - для вычисления предоплаченного трафика, (ВПР(B4;Тарифы!$A$4:$D$7;4;ИСТИНА) - для вычисления стоимости трафика, ВПР(B4;Тарифы!$A$4:$D$7;2;ИСТИНА) для вычисления абонентской платы. Размножим формулу с F4 по F7.

Рис. 4. Заполнение таблицы Начисления за услуги предоставления доступа к интернету

10. В ячейку поместим формулу =D4-F4. Размножим формулу с G4-G7.

11. В ячейку Н4 поместим формулу =G4*Курс!$C$4. Размножим формулу с Н4-Н7.

Рис. 5. Заполненная таблица Начисления за услуги доступа к интернету

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

Рис. 6. Вставка гистограммы

Рис. 6. Готовая гистограмма

9. Список использованной литературы

1. К. Вигерс "Разработка требований к программному обеспечению". Издательство "Русская редакция". Дата выхода: Январь 2004г. 330 стр.

2. Http://www.microsoft.com/Rus/Government/Newsletters/Issue22/02/04.mspx - Программа обеспечения безопасности внутренних приложений корпорации Microsoft.

Размещено на Allbest.ru