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

1. Защита Web-сайтов

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

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

сайт сервер уязвимость защищенность

2. Новое время - новые методы

Приведенный пример говорит о том, что прежний подход к безопасности безнадежно устарел. Угроз слишком много, и нужно что-то заложить в основу иерархии защиты. Интернет уже давно не просто сеть html-страниц. Это сложные приложения, скрипты, транспортная сеть, телеконференции, электронная почта и многое другое. Конечно, корпоративный firewall уже не решает всех проблем безопасности. Ведь равный и обобщенный подход к обеспечению безопасности данных каждого сотрудника компании неизбежно приводит к наличию брешей в защите. Из-за этого страдают нужды того или иного работника, когда оказываются закрыты критичные для выполнения работы ресурсы. Более того, многие системы безопасности отделяют от общего доступа только жизненно важные данные (например, бухгалтерский учет), в то время как остальные сведения, которые считаются менее важными, доступны всем. Конечно, это не означает, что сотрудники соседнего подразделения изучают данные своих коллег. Но такая открытость делает данные всех работников уязвимыми к атаке через одну-единственную лазейку в сети. Поэтому вместо порчи данных на 1-2 компьютерах страдают все.

Что и доказал червь Code Red. Эта одна из самых известных атак вскрыла множество проблем. Установлено: для того чтобы получить брешь в защите, необходимо сочетание трех факторов. Уязвимость программного обеспечения, протоколов или процессов, которыми может воспользоваться нападающий. Угроза со стороны враждебных инструментов, способных эту уязвимость использовать. Наконец, действие, а по сути, использование угрозы вашей уязвимости.

Еще в 1985 году Стив Беллоуин (Steve Bellovin), член Совета по архитектуре Интернета (Internet Architecture Board) опубликовал доклад об уязвимости TCP/IP-протокола. Хотя вплоть до 1996 года возникшая уязвимость оставалась под призрачной теоретической угрозой. Но угроза появилась, а привел ее в действие не кто иной, как Кевин Митник. Поэтому суть компьютерной безопасности не только в ее построении, но и в постоянном поиске уязвимости и устранении ее раньше, чем злоумышленники сумеют создать угрозу и привести ее в действие. Следовательно, безопасность - процесс динамический, а не статический. Анализ и устранения рисков - его основная составляющая, которой нельзя пренебрегать.

3. Почему веб-серверы так уязвимы?

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

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

Большинство веб-мастеров имеют корневой или администраторский доступ к серверу. Разумнее прописать каждому пользователю свою политику доступа, ограничивающую его права прямыми обязанностями. Например, сотрудник работает только с одним каталогом сервера, но имеет доступ на все остальные. Тем самым он ставит под угрозу не только свой сектор работ, но и все данные сервера. Конечно, статус веб-мастера имеет не каждый пользователь, хотя ограничить доступ из соображений безопасности следует и самым высоким профессионалам.

4. Информ безопасность

· Основные механизмы и средства защиты ресурсов информационных систем

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

· Значение рисков в современных системах информационной безопасности

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

· Методы управления информационными рисками

Понятие информационных рисков, остаточного и приемлемого рисков. Факторы, влияющие на изменение рисков. Основы управления информационными рисками. Понятие количественной и качественной оценки рисков, существующие программные реализации различных методов оценки рисков.

· Международный стандарт по информационной безопасности BS7799/ISO27002(17799)

Структура, значение и область применения стандарта. История его возникновения и краткое содержание.

· Аудит информационной безопасности

Понятие, цели и значение аудита ИБ. Нормы и правила проведения проверок и оценок ИБ. Критерии оценки деятельности аудиторов.

· Управление инцидентами ИБ

Значение управления инцидентами для обеспечения непрерывности бизнеса. Принципы, методы и способы управления инцидентами. Аварийный план, реагирование на инциденты, их расследование.

· Построение системы управления рисками информационной безопасности в соответствии с международным стандартом ISO 27005

Процесс управления рисками информационной безопасности. Элементы процесса. Стратегии обработки рисков. Выявление угроз и уязвимостей. Оценка и мониторинг рисков.

· Защита от внутренних нарушителей безопасности информационной системы

Актуальность и анализ проблемы нарушений требований информационной безопасности авторизованными пользователями информационной системы. Направления и принципы борьбы с подобными нарушениями.

· Нормативно-правовое обеспечение управления рисками ИБ

Значение законодательного уровня обеспечения ИБ, основные зарубежные и международные документы в этой области, анализ соответствующей казахстанской нормативной

Веб приложений

Безопасность Web-приложений уже не первый год является важным элементом защиты информационных систем. Учитывая тенденцию к переносу стандартных клиент-сервеных приложений в Web-среду, растущую популярность технологий AJAX и других элементов Web 2.0 можно констатировать, что с течением времени актуальность защиты онлайн-приложений только растет.

Безопасность Web-приложений уже не первый год является важным элементом защиты информационных систем. Учитывая тенденцию к переносу стандартных клиент-сервеных приложений в Web-среду, растущую популярность технологий AJAX и других элементов Web 2.0 можно констатировать, что с течением времени актуальность защиты онлайн-приложений только растет.

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

Базы данных уязвимостей

Ответить на вопрос о вероятности обнаружения той или иной проблемы можно с помощью информации из справочников (баз данных) уязвимостей. На сегодняшний день признанным отраслевым стандартом в этой области является список Common Vulnerabilities and Exposures (CVE) [1]. Однако непосредственно сам список слабо упорядочен и требует серьезной аналитической работы для получения полезных статистически результатов.

Ежегодно аналитиками Mitre проводится анализ информации в базе данных и публикуется отчет [2] о распределении уязвимостей по различным критериям. Согласно отчету более четверти проблем, обнаруженных в 2006 году, приходится на недостатки безопасности Web-приложений.

Аналогичную информацию публикуют и другие базы данных уязвимостей. По информации портала SecurityLab.ru, около 40% всех обнаруженных в 2007 уязвимостей приходится на Web-приложения (см. рис. 1).

Рис. 1 Распределение уязвимостей по типу приложений в 2007 году

Несмотря на то, что информация из баз данных уязвимостей достаточно интересна с теоретической точки зрения, она мало подходит для практического использования в рассматриваемом контексте. Это связанно с тем, что в базы данных попадает информация о широко распространенных приложениях, чье внедрение носит массовых характер. Что касается Web-приложений, то зачастую они создаются под конкретную задачу и могут быть развернуты только в одной сети или в единственном экземпляре. В последнее время наметилась тенденция публикации в базах данных информации не только об популярных Web-приложениях, но и в часто используемых on-line сервисах. Например - в общедоступных системах электронной почты, поисковых системах, социальных сетях и т.д. Однако пока это больше исключение, чем правило. Таким образом, ответить на вопрос «Насколько вероятно обнаружение уязвимости в Web-приложении» с помощью баз данных уязвимостей невозможно.

Анализ защищенности систем

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

В качестве примера подобных отчетов можно привести ежегодный отчет «Статистика уязвимости Web-приложений» компании Positive Technologies (PT) [4] и ежеквартальное обозрение «Website Security Statistics Report» компании WhiteHat Security (WH) [5]. Оба отчета имеют сходную структуру и содержат статистику уязвимостей Web-приложений, полученную в ходе работ по тестированию на проникновение, аудита безопасности и др. Для получения данных использовались различные подходы, от сканирования Web-приложений с помощью сканеров с последующей проверкой результатов до тестирования методом "белого ящика", включающего также частичный анализ исходного кода.

Оба отчета используют классификацию уязвимостей Web Application Security Consortium Web Security Threat Classification [6]. В этом документе собраны воедино и организованы различные угрозы безопасности Web-приложений. Проект является попытки разработки и популяризации стандартной терминологии описания проблем безопасности в Web-приложениях. Распространенные уязвимости Web-приложений организованны в структурированный список, состоящий из шести классов, каждый из которых содержит несколько типов уязвимостей и атак. В настоящее время готовится к публикации вторая редакция классификации, содержащая девять классов угроз. Оба отчета используют элементы  Web Security Threat Classification version 2 для описания таких проблем как «Расщепление HTTP-ответа» (HTTP Response Splitting) и «Подделка HTTP-запроса» (Cross-Site Request Forgery).

Интересно, что данные отчеты близки не только по структуре, но и по результатам. Так, наиболее распространенной уязвимостью оба источника признают «Межсайтовое выполнение сценариев» (Cross-Site Scripting, XSS). Эта уязвимость была обнаружена в 74% всех сайтов по версии Positive Technologies (см. рис. 2) и в 65 случаях из 100 (см. рис. 3) у клиентов WhiteHat Security.

Наиболее распространенной уязвимостью высокой степенью риска обе компании признают «Внедрение операторов SQL» (SQL Injection)  вероятность обнаружения которой составляет 31% - PT  и 16% - WH. Меньшая вероятность обнаружения проблем различных типов в трактовке WhiteHat Security вполне объяснима большей зрелостью западного рынка и использованием результатов повторных проверок приложений одного и того же клиента. К сожалению, большинство российских владельцев Web-приложений находится на этапе становления процесса управления информационной безопасностью.

В некоторых пунктах, например по количеству уязвимостей типа «Утечка информации» (Information Leakage) отчеты достаточно серьезно расходятся (90% - PT и 40% - WH). Это связанно с тем, что WhiteHat Security включает в отчет только уязвимости, имеющие «критичный», «неотложный» и «высокий» уровень риска, в то время как Positive Technologies задействует все найденные недочеты.

Рис. 2 Вероятность обнаружения уязвимостей различного типа (Positive Technologies)

Рис. 3 Вероятность обнаружения уязвимостей различного типа (WhiteHat Security)

Оценка степени риска

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

1. классическая «светофорная» оценка, выделяющая уязвимости «высокой», «средней» и «низкой» степени риска;

2. пятиуровневая модель, принятая в стандарте PSI DSS [7] и определяющая уровни «критичный», «неотложный», «высокий», «средний» и «низкий» (Urgent, Critical, High, Medium, Low)

3. метод Common Vulnerability Scoring System (CVSS) [8], оценивающий степень риска как число от 0 до 10.

Не касаясь достоинств или недостатков каждого из методов можно выделить следующие особенности, которые могут влиять на достоверность оценки:

1. зависимость от контекста;

2. зависимость от конфигурации системы;

3. зависимость от метода определения.

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

Конфигурация конкретной системы также может оказывать серьезное влияние на степень риска. Так, уязвимость «Внедрение операторов SQL» обычно классифицируют как имеющую высокую опасность. Однако в случае если Web-приложение работает с сервером СУБД с ограниченными привилегиями, она может быть отнесена к проблемам средней или низкой степени риска. В другой инсталляции или реализации приложения эта же уязвимость может быть использована для получения доступа к операционной системе с правами суперпользователя, что естественно делает её наиболее критичной.

В зависимости от метода у глубины анализа степень одна и та же уязвимость может быть оценена по-разному. Если взять приведенный выше пример  «Внедрения операторов SQL», использование сетевого сканера позволит только констатировать наличие проблемы. Для определения привилегий, доступных потенциальному злоумышленнику требуется либо попытаться использовать ошибку, либо уточнить порядок взаимодействия между Web-приложением и СУБД методом «белого ящика».

Каждый из приведенных методов оценки использует свои подходы для учета обозначенных обстоятельств. Это может быть абстрактное «экспертное мнение» в «светофорной» оценке или весовые коэффициенты в CVSS, но в любом случае - метод и глубина анализа оказывают серьезное влияние на оценку рисков. Это обстоятельство необходимо принимать внимание при работе с отчетами и статистическими данными.

5. Риски информационной безопасности веб-приложений

Информационная безопасность*, Блог компании Pentestit

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

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

Риски нужно контролировать постоянно, периодически проводя их переоценку. Отметим, что добросовестно выполненная и тщательно документированная первая оценка может существенно упростить последующую деятельность. Управление рисками, как и любую другую деятельность в области информационной безопасности, необходимо интегрировать в жизненный цикл информационной системы. Тогда эффект оказывается наибольшим, а затраты -- минимальными. Можно выделить основные этапы жизненного цикла информационной системы:

· инициация, согласно бизнес-процессам компании;

· установка;

· эксплуатация;

· выведение из эксплуатации.

Информационная система и её составляющие

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

· архитектура ИС;

· используемое аппаратное обеспечение;

· используемое программное обеспечение;

· системные интерфейсы (внутренняя и внешняя связность);

· топология сети;

· присутствующие в системе данные и информация;

· поддерживающий персонал и пользователи;

· миссия системы (то есть процессы, выполняемые ИС);

· критичность системы и данных;

· чувствительность (то есть требуемый уровень защищенности) системы и данных.

Действия: оценка технического задания функционала системы и её фактических составляющих.

Управление рисками

Управление рисками включает в себя два вида деятельности, которые чередуются циклически:

· регламентную оценку рисков;

· выбор эффективных и экономичных защитных средств (нейтрализация рисков).

По отношению к выявленным рискам возможны следующие действия:

· ликвидация риска (например, за счет устранения уязвимости);

· уменьшение риска (например, за счет использования дополнительных защитных средств или действий);

· принятие риска (и выработка плана действия в соответствующих условиях).

Управление рисками можно подразделить на следующие этапы:

· инвентаризация анализируемых объектов;

· выбор методики оценки рисков;

· идентификация активов;

· анализ угроз и их последствий;

· определение уязвимостей в защите;

· оценка рисков;

· выбор защитных мер;

· реализация и проверка выбранных мер;

· оценка остаточного риска.

Для определения основных рисков можно следовать следующей цепочке: источник угрозы > фактор (уязвимость) > угроза (действие) > последствия (атака).

· Источник угрозы -- это потенциальные антропогенные, техногенные или стихийные носители угрозы безопасности.

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

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

· Последствия (атака) -- это возможные последствия реализации угрозы (возможные действия) при взаимодействии источника угрозы через имеющиеся факторы (уязвимости).

Действия: внедрение политики информационной безопасности компании.

Источник угрозы

Антропогенными источниками угроз безопасности информации выступают субъекты, действия которых могут быть квалифицированы как умышленные или случайные преступления. Методы противодействия напрямую зависят от организаторов защиты информации.

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

Внешние источники могут быть случайными или преднамеренными и иметь разный уровень квалификации. К ним относятся:

· криминальные структуры;

· потенциальные преступники и хакеры;

· недобросовестные партнеры;

· технический персонал поставщиков телематических услуг;

· представители надзорных организаций и аварийных служб;

· представители силовых структур.

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

· основной персонал (пользователи, программисты, разработчики);

· представители службы защиты информации.

Действия: составление вероятностной шкалы источников угроз.

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