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

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

· контроль над копированием программного обеспечения, защищенного законом об авторском праве;

· защита документации организации;

· защита данных;

· контроль соответствия политике безопасности.

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

2.6 Международный стандарт ISO 15408 - «Общие критерии»

Международный стандарт ИСО/МЭК15408-99 (исторически сложившееся название - «Общие критерии») представляет собой результат обобщения опыта различных государств по разработке и практическому использованию критериев оценки безопасности информационных технологий(ИТ). Базовые документы, которые легли в основу «Общих критериев», и связи между ними представлены на рис 3.1.

Анализ развития нормативной базы оценки безопасности ИТ позволяет понять те мотивационные посылки, которые привели к созданию «Общих критериев».

Рис. 2.1. Предыстория«Общих критериев»

Общие критерии оценки безопасности информационных технологий (далее «Общие критерии») определяют функциональные требования безопасности (security functional requirements) и требования к адекватности реализации функций безопасности (security assurance requirements).

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

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

Разработка этого стандарта преследовала следующие основные цели:

· унификация национальных стандартов в области оценки безопасности ИТ;

· повышение уровня доверия к оценке безопасности ИТ;

· сокращение затрат на оценку безопасности ИТ на основе взаимного признания сертификатов.

Новые критерии были призваны обеспечить взаимное признание результатов стандартизованной оценки безопасности на мировом рынке ИТ.

Первая часть. «Общих критериев» содержит определение общих понятий, концепции, описание модели и методики проведения оценки безопасности ИТ. В ней вводится понятийный аппарат и определяются принципы формализации предметной области.

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

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

· наличие побочных каналов утечки информации;

· ошибки в конфигурации, либо неправильное использование системы, приводящее к переходу системы в небезопасное состояние;

· недостаточная надежность (стойкость) механизмов безопасности, реализующих соответствующие функции безопасности;

· наличие уязвимостей («дыр») в средствах защиты информации, позволяющих пользователям получать НСД к информации в обход существующих механизмов защиты.

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

Основными отличительными чертами ОК являются:

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

· общие критерии, которые характеризуются наиболее полной на сегодняшний день совокупностью требований безопасности ИТ;

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

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

· систематизация и классификация требований по иерархии «класс - семейство - компонент - элемент» с уникальными идентификаторами требований, которые обеспечивают удобство их использования;

· компоненты требований в семействах и классах, которые ранжированы по степени полноты и жесткости, а также сгруппированы в пакеты требований;

· гибкость в подходе к формированию требований безопасности для различных типов изделий ИТ и условий их применения обеспечиваемые возможностью целенаправленного формирования необходимых наборов требований в виде определенных в ОК стандартизованных структурах (профилях защиты и заданий по безопасности);

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

По уровню систематизации, полноте и возможностям детализации требований, универсальности и гибкости в применении ОК представляют

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

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

2.7 Стандарт COBIT

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

На основе этой концепции описываются элементы информационной технологии, даются рекомендации по организации управления и обеспечению режима информационной безопасности. Концепция изложена в документе под названиемCOBIT 3rd Edition (Control Objectives for Information and Related Technology - Контрольные объекты информационной технологии), который состоит из четырех частей

· часть 1 - краткое описание концепции (Executive Summary);

· часть 2 - определения и основные понятия (Framework).

Помимо требований и основных понятий, в этой части сформулированы требования к ним;

· часть 3 - спецификации управляющих процессов и возможный инструментарий(Control Objectives);

· часть 4 - рекомендации по выполнению аудита компьютерных информационных систем(Audit Guidelines).

Третья часть этого документа в некотором смысле аналогична международному стандарту BS 7799. Примерно так же подробно приведены практические рекомендации по управлению информационной безопасностью, но модели систем управления в сравниваемых стандартах сильно различаются. Стандарт COBIT - пакет открытых документов, первое издание которого было опубликовано в 1996 году. COBIT описывает универсальную модель управления информационной технологией, представленную на рис. 2.2

Рис. 2.2. Структура стандарта COBIT

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

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

В стандарте COBIT выделены следующие этапы проведения аудита.

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

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

Анализ исходных данных проводится только с учетом достоверных исходных данных. Требования к проведению анализа определяются на этапе сбора исходных данных. Стандарт COBIT рекомендует применять описанные в стандарте методики анализа данных, но при необходимости допускается использование разрешенных ISACA разработок других членов ассоциации. На этапе анализа возможен возврат к этапу сбора информации для получения недостающих исходных данных.

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

Контроль за выполнением рекомендаций подразумевает постоянное отслеживание аудиторской компанией выполнения заказчиком рекомендацией.

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

Любая работающая информационная технология в модели COBIT проходит следующие стадии жизненного цикла:

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

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

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

Мониторинг. За процессами информационной технологии необходимо наблюдать и контролировать соответствие их параметров выдвинутым требованиям. Выделяется 4 основные задачи, решаемые на данной стадии. Всего в стандарте COBIT выделяется 34 задачи верхнего уровня обработки информации (рис. 2.2).

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

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

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

Отличительные чертыCOBIT:

1. Большая зона охвата (все задачи от стратегического планирования и основополагающих документов до анализа работы отдельных элементов ИС).

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

3. Адаптируемый, наращиваемый стандарт.

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

Представленная на рис 2.3 блок-схема отражает, хотя и не в деталях, ключевые точки проведения аудита ИС с использованием стандартаCOBIT. Рассмотрим их подробнее. На этапе подготовки и подписания исходно-разрешительной документации определяются границы проведения аудита:

· Границы аудита определяются критическими точками ИС (элементами ИС), в которых наиболее часто возникают проблемные ситуации.



Рис. 2.3. Общая последовательность проведения аудита

· На основании результатов предварительного аудита всей ИС (в первом приближении) проводится углубленный аудит выявленных проблем.

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

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

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

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

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

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

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

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

Глава III. Программные средства для проведения аудита информационной безопасности

3.1 Анализ видов используемых программных продуктов

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

Все эти задачи решить на основе использования «бумажных» методик не всегда предоставляется возможным.

Поэтому фирмы, занимающиеся проведением внешнего аудита используют различные программные продукты, которые можно разделить по назначению и методике использования на два вида:

1) инструментарий для анализа и управления рисками;

2) средства анализа защищенности информационных систем.

Первый вид программных систем построен на использовании методик одного из видов международных стандартов BS 7799 (метод CRAMM), стандарте ISO 17799 (система COBRA и система Кондор), американских стандартов в области анализа и управления рисками (RiskWatch).

Второй вид программных средств ориентирован на анализ защищенности автоматизированных систем (АС). Здесь можно выделить две группы систем, основанных:

· на использовании технологии интеллектуальных программных агентов(например, система ESM компании Symantec )

· использовании метода анализа на основе активного тестирования механизмов защиты путем эмуляции действий злоумышленника по осуществлению попыток сетевого вторжения в АС.

В качестве примера систем, использующих этот метод, могут быть приведены сетевые сканеры и наиболее известные из них Nessus.

Ниже рассмотрены общие характеристики названных систем.

3.2 Система CRAMM

Этот метод и программный комплекс на его основе был разработан в Великобритании(в1985г.) и в дальнейшем доработан с учетом требований Британского стандарта BS 7799, принятого в1995г.

В настоящее время CRAMM является, судя по числу ссылок в Интернет, самым распространенным методом анализа и контроля рисков.

Целью разработки метода являлось создание формализованной

процедуры, позволяющей:

1. убедиться, что требования, связанные с безопасностью, полностью проанализированы и документированы;

2. избежать расходов на излишние меры безопасности, возможные при субъективной оценке рисков;

3. оказывать помощь в планировании и осуществлении защиты на всех стадиях жизненного цикла информационных систем;

4. обеспечить проведение работ в сжатые сроки;

5. автоматизировать процесс анализа требований безопасности;

6. представить обоснование для мер противодействия;

7. оценивать эффективность контрмер, сравнивать различные варианты контрмер;

8. генерировать отчеты.

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

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

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

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

· угрозы идентифицированы и их уровни оценены;

· контрмеры эффективны;

· расходы, связанные с ИБ, оправданы. уверенность в том, что:

Выполнение автоматизированных процедур в рамках метода CRAMM предполагает выделение трех последовательных этапов.

На первом этапе проводится анализ применяемых средств базового уровня системы защиты и делается заключение о соответствии уровню рисков.

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

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

На третьем этапе решается задача управления рисками, состоящая в выборе адекватных контрмер.

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

В случае принятия решения о внедрении новых контрмер и модификации старых, на аудитора может быть возложена задача подготовки плана внедрения новых контрмер и оценки эффективности их использования. Решение этих задач выходит за рамки метода CRAMM.

Общая схема анализа угроз, уязвимостей и выбора контрмер показана на рис. 3.1.

Рис. 3.1. Концептуальная схема проведения обследования по методу CRAMM

Процедура аудита в методеCRAMM является формализованной.

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

Так, на первом этапе создаются следующие виды отчетов:

· Модель ресурсов, содержащая описание ресурсов, попадающих в границы исследования, и взаимосвязей между ними.

· Оценка критичности ресурсов.

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

На втором этапе проведения обследования создаются следующие виды отчетов:

· Результаты оценки уровня угроз и уязвимостей.

· Результаты оценки величины рисков.

· Результирующий отчет по второму этапу анализа рисков.

По результатам третьего этапа обследования создаются следующие виды отчетов:

· Рекомендуемые контрмеры.

· Детальная спецификация безопасности.

· Оценка стоимости рекомендуемых контрмер.

· Список контрмер, отсортированный в соответствии с их приоритетами.

· Результирующий отчет по третьему этапу обследования.

· Политика безопасности, включающая в себя описание требований безопасности, стратегий и принципов защиты ИС.

· Список мероприятий по обеспечению безопасности.

Особого внимания заслуживают возможности CRAMM по автоматической генерации нескольких вариантов мер противодействия, адекватных выявленным рискам и их уровням, число которых в базе данных системы составляет более1000. Все контрмеры разбиты на 61 группу:

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

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

· протоколирование;

· аудит;

· безопасность многократного использования объектов;

· тестирование систем;

· контроль целостности ПО;

· управление вводом/выводом;

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

· обеспечение неотказуемости;

· обеспечение конфиденциальности вне соединения;

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

· физическая безопасность сети;

· защита сообщений;

· обеспечение целостности данных вне соединения;

· сохранение правильной последовательности сообщений;

· пополнение трафика;

· контроль операций в системе;

· контроль действий системного администратора;

· контроль действий прикладных программистов;

· контроль операций по поддержке прикладного ПО;

· контроль операций по обслуживанию СВТ;

· контроль пользователей;

· контроль ввода/вывода приложений;

· финансовая отчетность;

· контроль выходных документов;

· контроль носителей данных;

· контроль транспортировки физических носителей данных;

· резервное копирование и восстановление для серверов;

· резервирование и восстановление сетевых интерфейсов;

· резервирование и восстановление сетевых сервисов;

· восстановление помещений;

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

· планирование восстановления;

· резервное копирование данных;

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

· защита от сбоев СВТ;

· обеспечение физической безопасности помещений;

· оптимизация расположения СВТ в помещениях;

· организация зон безопасности;

· защита от краж;

· физическая защита СВТ;

· контрмеры против террористов и экстремистов;

· защита средств контроля доставки;

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

· защита от минирования со стороны сотрудников и посторонних

· лиц;

· защита от пожара;

· защита от затоплений;

· защита от природных катаклизмов;

· защита источников электропитания;

· защита поддерживающей инфраструктуры;

· защита персонала;

· обучение персонала;

· политика безопасности;

· инфраструктура безопасности;

· оповещение об инцидентах;

· проверка жалоб.

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

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

К сильным сторонам методаCRAMM относится следующее:

· CRAMM является хорошо структурированным и широко опробованным методом анализа рисков, позволяющим получать реальные практические результаты.

· Программный инструментарийCRAMM может использоваться на всех стадиях проведения аудита безопасности ИС.

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

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

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

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

К недостаткам метода CRAMM можно отнести следующее:

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

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

· Аудит по методу CRAMM - процесс достаточно трудоемкий и может потребовать месяцев непрерывной работы аудитора.

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

· CRAMM не позволяет создавать собственные шаблоны отчетов или модифицировать имеющиеся.

· Возможность внесения дополнений в базу знаний CRAMM не доступна пользователям, что вызывает определенные трудности при адаптации этого метода к потребностям конкретной организации.

3.3 Система КОНДОР

Существует целый ряд зарубежных и отечественных систем, позволяющих провести проверку соответствия информационной системы требованием стандарта ISO 17799. В основе этих программных комплексов лежит использование принципов экспертных систем, включающих обширные базы знаний по угрозам и уязвимостям и большое количество вопросников. Наиболее известной из зарубежных систем этого класса является система COBRA. Аналогом подобной системы является система КОНДОР, разработанная российской консалтинговой компанией Digital Security .

Рассмотрим более подробно эту систему.

КОНДОР - предназначен для проверки соответствия политики информационной безопасности предприятия требованиям ISO 17799.

КОНДОР включает в себя более200 вопросов, соответствующих 10 направлениям, определяемых стандартом ISO 17799.

Принцип работы системы заключается в постановке вопросов пользователю и составлении рекомендаций и отчетов на их основе. На рис. 3.2 представлено рабочее окно системы КОНДОР при анализе направления "Контроль доступа" в компании.

После определения ответов на поставленные вопросы система Кондор создает отчеты, которые включают:

1. Ответы на вопросы

2. Диаграммы и статистику (представлена на рис. 3.3)

3. Анализ рисков

Данные, представленные в разделе «Диаграммы и статистика» и «Анализ рисков», являются результатом работы системы и могут быть использованы при оценке информационной безопасности компании.



Рис. 3.2. Вопросы анализа по направлению «Контроль доступа» в системе КОНДОР

Рис. 3.3. Диаграммы и статистика в системе КОНДОР

Кроме анализа система КОНДОР предоставляет ряд документов, требований и инструкций, которые могут помочь специалисту в разработке общей политики безопасности компании.

К недостаткам системы "КОНДОР" можно отнести:

· отсутствие возможности установки пользователем значимости каждого требования;

· отсутствие возможности внесения пользователем комментариев.

Демо-версия системы доступна для скачивания и изучения с официального сайта разработчиков http://www.dsec.ru/.

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

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

3.4 Сетевые сканеры

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

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

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

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

Современный сетевой сканер выполняет четыре основные задачи:

· идентификация доступных сетевых ресурсов;

· идентификация доступных сетевых сервисов;

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

· выдача рекомендаций по устранению уязвимостей.

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

Принцип работы сканера заключается в моделировании действия злоумышленника, производящего анализ сети при помощи стандартных сетевых утилит, таких какhost, showmount, traceout, rusers, finger, ping и т. п. При этом используются известные уязвимости сетевых сервисов, сетевых протоколов и ОС для осуществления удаленных атак на системные ресурсы и осуществляется документирование удачных попыток.

В настоящее время существует большое количество как коммерческих, так и свободно распространяемых сканеров, как универсальных, так и специализированных - предназначенных для выявления только определенного класса уязвимостей. Многие из них можно найти в сети Интернет. Число уязвимостей в базах данных современных сканеров медленно, но уверенно приближается к1000. Одним из наиболее продвинутых коммерческих продуктов этого класса является сетевой сканер NetRecon компании Symantec, база данных которого содержит около800 уязвимостей UNIX, Windows и NetWare систем и постоянно обновляется черезWeb. Рассмотрение его свойств позволит составить представление обо всех продуктах этого класса. Сетевой сканер Nessus может рассматриваться в качестве достойной альтернативы коммерческим сканерам. Nessus является свободно распространяемым и постоянно обновляемым программным продуктом. Удобный графический интерфейс позволяет определять параметры сеанса сканирования, наблюдать за ходом сканирования, создавать и просматривать отчеты.

По своим функциональным возможностям сканер защищенности Nessus находится в одном ряду, а по некоторым параметрам и превосходит такие широко известные коммерческие сканеры, как NetRecon компании Symantec, Internet Scanner компании ISS и CyberCop Scanner компанииNAI.

Версии 0.99 серверной части сканера Nessus была сертифицирована в Гостехкомиссии России (Сертификат N 361 от18 сентября2000 г.).

Сценарии атак реализованы в NESSUS в качестве подключаемых модулей (plugins). Количество подключаемых модулей постоянно увеличивается, в настоящее время насчитывается более700. Новые внешние модули, эмулирующие атаки, можно инсталлировать, скопировав файлы, содержащие их исходные тексты, с web - сервера разработчиков www.nessus.org.

Nessus предоставляет очень широкие возможности по поиску уязвимостей корпоративных сетей и исследованию структуры сетевых сервисов. Помимо использования стандартных способов сканирования ТСР и UDP портов, Nessus позволяет осуществлять поиск уязвимостей в реализациях протоколов управления сетью ICMP и SNMP. Кроме того, поддерживаются различные стелс - режимы сканирования, реализуемые популярным некоммерческим стелс - сканером nmap, который можно рассматривать в качестве одного из компонентов сканера Nessus. Другой популярный некоммерческий сканер queso используется в составе Nessus для определения типа и номера версии сканируемой ОС.

Высокая скорость сканирования достигается за счет использования при реализации сканера Nessus много потоковой архитектуры программирования, позволяющей осуществлять одновременное параллельное сканирование сетевых хостов. Для сканирования каждого хоста сервером nessusd создается отдельный поток выполнения.

Подробное описание используемых методов сканирования TCP/UDP портов можно найти в онлайновой документации на сканер nmap.

При реализации Nessus использована нетипичная для сетевых сканеров клиент/серверная архитектура. Взаимодействие между клиентом и сервером осуществляется по защищенному клиент-серверному протоколу, предусматривающему использование надежной схемы аутентификации и шифрование передаваемых данных. Сервер nessusd работает только в среде UNIX и предназначен для выполнения сценариев сканирования. Механизмы собственной безопасности, реализованные в сервере nessusd, позволяют осуществлять аутентификацию пользователей сканера, ограничивать полномочия пользователей по выполнению сканирования и регистрировать все действия пользователей в журнале регистрации событий на сервере.

Клиентская часть Nessus работает и в среде UNIX, и в среде Windows и реализует графический интерфейс пользователя для управления сервером nessusd. Пользователь сканера перед запуском сеанса сканирования определяет параметры сканирования, указывая диапазон сканируемых IP-адресов и TCP/UDP портов, максимальное количество потоков сканирования(число одновременно сканируемых хостов), методы и сценарии сканирования (plugins), которые будут использоваться.

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

· Backdoors для обнаружения "троянских" программ;

· Gain Shell Remotely - для реализации атак на получение пользовательских полномочий на удаленной UNIX системе;

· Firewalls - для тестирования МЭ;

· FTP - для тестирования FTP-серверов;

· Windows - для поиска уязвимостей Windows-систем и т.п.

Особую группу сценариев сканирования Denail of Service составляют атаки на отказ в обслуживании(DoS). Единственный способ убедиться в том, что сканируемая система подвержена той или иной DoS - это выполнить эту атаку и посмотреть на реакцию системы. Эта группа сценариев, однако, является потенциально опасной, т.к. их запуск может привести к непредсказуемым последствиям для сканируемой сети, включая сбои в работе серверов и рабочих станций, потерю данных и полный паралич" корпоративной сети. Поэтому большинство DoS в данной группе по умолчанию отключено.

Для написания сценариев атак служит специализированный С-подобный язык программирования высокого уровня NASL (Nessus Attack Scripting Language). Существует также интерфейс прикладного программирования(API) для разработки подключаемых модулей со сценариями атак на языкеC, однако, предпочтительным является все же использование NASL.

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

Результаты работы сканера Nessus представляются в виде специальных протоколов. Данные об обнаруженных уязвимостях сортируются по IP-адресам просканированных хостов. Найденные уязвимости могут быть про ранжированы. Наиболее критичные (security holes) уязвимости выделяются красным цветом, менее критичные (security warning) - желтым. По каждой уязвимости приводится ее описание, оценка ассоциированного с ней риска (Risk Factor) и рекомендации по ее ликвидации (Solution).

Заключение

Результатами проведения аудита Информационной Безопасности позволяют:

ь выявить значимые угрозы для информации, циркулирующей в пределах предприятия;

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

ь составить неформальную модель нарушителя; определить основные требования к системе защиты;

ь оценить с точки зрения этих требований эффективность применяемых организационных мер и инженерно-технических средств защиты;

ь разработать предложения и рекомендации по совершенствованию комплексной системы обеспечения безопасности.

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

ь выявить значимые угрозы для информации, циркулирующей в пределах предприятия;

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

ь составить неформальную модель нарушителя; определить основные требования к системе защиты;

ь оценить с точки зрения этих требований эффективность применяемых организационных мер и инженерно-технических средств защиты;

ь разработать предложения и рекомендации по совершенствованию комплексной системы обеспечения безопасности.

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

ь защиту от проникновения в корпоративную сеть и от утечки информации из сети по каналам связи;

ь защиту наиболее критичных ресурсов сети от вмешательства в нормальный процесс функционирования;

ь защита важных рабочих мест и ресурсов от несанкционированного доступа;

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

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

Объективно оценить безопасность всех основных компонентов и сервисов корпоративной информационной системы предприятия заказчика, техническое состояние аппаратно-программных средств защиты информации

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

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

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

1. Аверченков В.И. Организационная защита информации: учеб. пособие/В.И. Аверченков, М.Ю. Рытов - Брянск: БГТУ, 2005 - 184с.

2. Аверченков В.И., Служба защиты информации: организация и управление: учеб. пособие / В.И. Аверченков, М.Ю. Рытов - Брянск: БГТУ, 2005 - 186с.

3. Астахов А. Аудит безопасности информационных систем / А.Астахов

4. Галатенко В.А. Основы информационной безопасности: учеб. пособие/В.А. Галатенко - М: ИНТУИТ.РУ «Интернет-университет информационных технологий», 2004. - 264с.

5. Домарев В.В. Безопасность информационных технологий. Системный подход / В.В. Домарев - Киев: ООО «ТиД», 2004. - 914с.

6. Линаев В.В. Технологические процессы и стандарты обеспечения функциональной безопасности в жизненном цикле программных средств / В.В. Линаев. - 2004. - №3 (130).

7. Мак-Мак В.П. Служба безопасности предприятия. Организационно-управленческие и правовые аспекты деятельности/В.П. Мак-Мак - М.: ИД МБ, 1999. -160 с.

8. Медведовский И.Д. Практическое применение международного стандарта безопасности информационных систем ISO 17799

9. Медведовский И.Д. Современные методы и средства анализа и контроля рисков информационных компаний

10. Петренко С.А. Аудит безопасности Iuranrt / С.А. Петренко, А.А. Петренко - М: Академии АиТи: ДМК Пресс, 2002. - 438с.

11. Петренко С.А. Управление информационными рисками. Экономически оправданная безопасность/ С.А. Петренко, С.В. Симонов - М: Академия АиТи: ДМК Пресс, 2004. - 384с.

12. Петренко С.А. Возможная методика построения системы информационной безопасности предприятия

13. Покровский П. Оценка информационных рисков/ П. Покровский - 2004. - №10. Изд-во «Открытые системы»

14. Симонов С. Анализ рисков, управление рисками

15. Хованов В.И. О системном подходе к проблеме страхования информационных рисков//Information Security. - 2004.-№3, (www.itsec.ru).

16. Ярочкин, В.И. Система безопасности фирмы / В.И. Ярочкин - М: «Ось-89», 2003 - 352с.

17. Астахов, А. Анализ защищенности корпоративных автоматизированных систем / А. Астахов // Jet Info online. - 2002.-№7(10),

18. Бетелин В.Б. и др. Профили защиты на основе «Общих критериев» / В.Б. Бетелин, В.А. Галатенко [и др.]// Jet Info on line. - 2003.- №3 (118), 2003/3/1/фкешсду1.3. 2003.

19. Галатенко А. Активный аудит/ А. Галатенко // Jet Info on line.- 1999.- №8(75). article 1.8. 1999……

20. Гузик С. Зачем проводить аудит информационных систем? /С. Гузик // Jet Info on line. - 2000. - 10 (89). articlel.10.2000.

21. Кобзарев М Методология оценки безопасности информационных технологий по общим критериям / М. Кобзарев, А. Сидак // Jet Info on line. - 2004. - 6 (133). article 1.6.2004.

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