Учебная работа .Тема:Аудит информационной безопасности № 1080.

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

Введение

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

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

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

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

Общая структура работы включает следующую последовательность рассматриваемых вопросов:

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

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

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

анализируются основные международные и российские стандарты, используемые при проведении аудита ИБ;

показываются возможности использования программных средств для проведения аудита ИБ;

даются практические рекомендации по проведению аудита ИБ на предприятии.

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

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

Глава I. Аудит безопасности и методы его проведения

.1 Понятие аудита безопасности

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

Целями проведения аудита безопасности являются:

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

оценка текущего уровня защищенности ИС;

локализация узких мест в системе защиты ИС;

оценка соответствия ИС существующим стандартам в области информационной безопасности;

выработка рекомендаций по внедрению новых и повышению эффективности существующих механизмов безопасности ИС.

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

Для проведения аудита безопасности предприятия может быть рекомендована следующая последовательность действий .

1. Подготовка к проведению аудита безопасности:

выбор объекта аудита (фирма, отдельные здания и помещения, отдельные системы или их компоненты);

составление команды аудиторов экспертов;

определение объема и масштаба аудита и установление конкретных сроков работы.

2.Проведение аудита:

общий анализ состояния безопасности объекта аудита;

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

оценка результатов проверки;

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

3.Завершение аудита:

составление итогового отчета;

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

Для успешного проведения аудита безопасности необходимо:

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

объективность и независимость аудиторов (экспертов), их компетентность и высокая профессиональность;

четко структурированная процедура проверки;

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

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

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

В зависимости от объема анализируемых объектов предприятия определяются масштабы аудита:

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

аудит безопасности отдельных зданий и помещений (выделенные помещения);

аудит оборудования и технических средств конкретных типов и видов;

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

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

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

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

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

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

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

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

Границы проведения обследования определяются в следующих категориях:

. Список обследуемых физических, программных и информационных ресурсов.

2.Площадки (помещения), попадающие в границы обследования.

3.Основные виды угроз безопасности, рассматриваемые при проведении аудита.

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

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

Для понимания аудита ИБ как комплексной системы может быть использована его концептуальная модель, показанная на рис. 1.1. Здесь выделены главные составляющие процесса:

объект аудита:

цель аудита:

Рис. 1.1 . Концептуальная модель аудита ИБ

предъявляемые требования;

используемые методы;

масштаб:

исполнители;

порядок проведения.

С точки зрения организации работ при проведении аудита ИБ выделяют три принципиальных этапа:

1.сбор информации;

2.анализ данных;

3.выработка рекомендаций и подготовка отчетных документов.

Ниже более подробно рассмотрены эти этапы.

.2 Методы анализа данных при аудите ИБ

В настоящее время используются три основных метода (подхода) к проведению аудита, которые существенно различаются между собой [3].

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

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

Третий метод, наиболее эффективный, предполагает комбинирование первых двух.

Если для проведения аудита безопасности выбран подход, базирующийся на анализе рисков, то на этапе анализа данных аудита обычно выполняются следующие группы задач [3]:

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

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

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

4.Оценка критичности информационных ресурсов, а также программных и технических средств.

5.Определение критичности ресурсов с учетом их взаимозависимостей.

6.Определение наиболее вероятных угроз безопасности в отношении ресурсов ИС и уязвимостей защиты, делающих возможным осуществление этих угроз.

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

8.Определение величины рисков для каждой тройки: угроза группа ресурсов уязвимость.

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

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

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

.3 Анализ информационных рисков предприятия

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

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

1.Идентификация ключевых ресурсов ИС.

2.Определение важности тех или иных ресурсов для организации.

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

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

Ресурсы ИС можно разделить на следующие категории:

информационные ресурсы;

программное обеспечение;

технические средства (серверы, рабочие станции, активное сетевое оборудование и т. п.);

людские ресурсы.

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

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

данные были раскрыты, изменены, удалены или стали недоступны;

аппаратура была повреждена или разрушена;

нарушена целостность программного обеспечения.

Ущерб может быть нанесен организации в результате успешного осуществления следующих видов угроз безопасности:

локальные и удаленные атаки на ресурсы ИС;

стихийные бедствия;

ошибки, либо умышленные действия персонала ИС;

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

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

стоимость ресурса х вероятность угрозы Риск = величина уязвимости

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

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

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

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

·ошибок в программном обеспечении(в том числе недокументированных возможностей).

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

При проведении анализа риска разрабатываются:

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

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

·сценарий осуществления противоправных действий;

·характеристики каналов утечки информации и НСД;

·вероятности установления информационного контакта (реализации угроз);

·перечень возможных информационных инфекций;

·модель нарушителя;

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

Кроме того, для построения надежной системы защиты информации предприятия необходимо:

·выявить все возможные угрозы безопасности информации;

·оценить последствия их проявления;

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

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

·оценить эффективность выбранных мер и средств защиты.

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

Рис. 1.2. Сценарий анализа информационных ресурсов

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

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

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

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

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

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

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

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

На сегодня известно несколько подходов к управлению рисками.

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

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

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

1.4 Методы оценивания информационных рисков предприятия

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

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

·оценивание возможных угроз;

·оценивание существующих уязвимостей;

·оценивание эффективности средств обеспечения информационной безопасности.

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

·от показателей ценности информационных ресурсов;

·вероятности реализации угроз для ресурсов;

·эффективности существующих или планируемых средств обеспечения ИБ.

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

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

·привлекательностью ресурса используется при рассмотрении угрозы от умышленного воздействия со стороны человека;

·возможностью использования ресурса для получения дохода при рассмотрении угрозы от умышленного воздействия со стороны человека;

·техническими возможностями реализации угрозы применяется при умышленном воздействии со стороны человека;

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

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

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

·безопасность персонала;

·разглашение частной информации;

·требования по соблюдению законодательных и нормативных положений;

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

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

·финансовые потери и нарушения в производственной деятельности;

·общественные отношения;

·коммерческую политику и коммерческие операции;

·потерю репутации компании.

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

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

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

Общий алгоритм процесса оценивания рисков (рис.1.3.) в этих системах включает следующие этапы.

·описание объекта и мер защиты;

·идентификация ресурса и оценивание его количественных показателей (определение потенциального негативного воздействия на бизнес);

·анализ угроз информационной безопасности;

·оценивание уязвимостей;

·оценивание существующих и предполагаемых средств

обеспечения информационной безопасности;

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

.5 Управление информационными рисками

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

Рис. 1.3. Алгоритм оценивания рисков

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

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

)(пере) оценка (измерение) рисков;

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

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

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

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

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

·переадресация риска(например, путем заключения страхового соглашения).

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

1.Выбор анализируемых объектов и уровня детализации их рассмотрения.

2.Выбор методологии оценки рисков.

.Идентификация активов.

.Анализ угроз и их последствий, выявление уязвимых мест в защите.

.Оценка рисков.

.Выбор защитных мер.

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

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

Этапы6 и относятся к выбору защитных средств(нейтрализациии рисков), остальные к оценке рисков.

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

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

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

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

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

На этапе установки выявленные риски следует учитывать при конфигурировании, тестировании и проверке ранее сформулированных

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

На этапе эксплуатации управление рисками должно сопровождать все существенные изменения в системе.

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

Глава II. Стандарты информационной безопасности

.1 Предпосылки создания стандартов ИБ

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

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

Использование стандартов способствует решению следующих пяти задач.

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

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

)Критерий оценки надежности компьютерных систем «Оранжевая книга» (США);

)Гармонизированные критерии европейских стран;

)Рекомендации Х.800;

)Германский стандартBSI;

)Британский стандартBS 7799;

)СтандартISO 17799;

)Стандарт«Общие критерии» ISO 15408;

)СтандартCOBIT

Эти стандарты можно разделить на два вида:

·Оценочные стандарты, направленные на классификацию информационных систем и средств защиты по требованиям безопасности;

·Технические спецификации, регламентирующие различные аспекты реализации средств защиты.

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

.2 Стандарт «Критерии оценки надежности компьютерных систем» (Оранжевая книга)

Исторически первым оценочным стандартом, получившим широкое распространение и оказавшим огромное влияние на базу стандартизации ИБ во многих странах, стал стандарт Министерства обороны США«Критерии оценки доверенных компьютерных систем».

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

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

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

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

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

Степень доверия оценивается по двум основным критериям.

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

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

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

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

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

Монитор обращений должен обладать тремя качествами:

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

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

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

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

Границу доверенной вычислительной базы называют периметром безопасности. Как уже указывалось, компоненты, лежащие вне периметра безопасности, вообще говоря, могут не быть доверенными. С развитием распределенных систем понятию «периметр безопасности» все чаще придают другой смысл, имея в виду границу владений определенной организации. То, что находится внутри владений, считается доверенным, а то, что вне, нет.

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

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

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

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

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

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

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

.3 Германский стандарт BSI

В 1998 году в Германии вышло «»Руководство по защите информационных технологий для базового уровня»». Руководство представляет собой гипертекст объемом около 4 МБ (в форматеHTML). В дальнейшем оно было оформлено в виде германского стандарта BSI. В его основе лежит общая методология и компоненты управления информационной безопасностью:

·Общий метод управления информационной безопасностью (организация менеджмента в области ИБ, методология использования руководства).

·Описания компонентов современных информационных технологий.

·Основные компоненты (организационный уровень ИБ, процедурный уровень, организация защиты данных, планирование действий в чрезвычайных ситуациях).

·Инфраструктура (здания, помещения, кабельные сети, организация удаленного доступа).

·Клиентские компоненты различных типов (DOS, Windows, UNIX, мобильные компоненты, прочие типы).

·Сети различных типов (соединения «точка точка», сети Novell NetWare, сети с OC ONIX и Windows, разнородные сети).

·Элементы систем передачи данных (электронная почта, модемы, межсетевые экраны и т.д.).

·Телекоммуникации (факсы, автоответчики, интегрированные системы на базе ISDN, прочие телекоммуникационные системы).

·Стандартное ПО.

·Базы данных.

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

·Характеристики объектов информатизации (здания, помещения, кабельные сети, контролируемые зоны).

·Характеристики основных информационных активов компании (в том числе аппаратное и программное обеспечение, например рабочие станции и сервера под управлением операционных систем семейства DOS, Windows и UNIX).

·Характеристики компьютерных сетей на основе различных сетевых технологий, например сети Novell Net Ware, сети UNIX и Windows).

·Характеристика активного и пассивного телекоммуникационного оборудования ведущих вендоров, например Cisco Systems.

·Подробные каталоги угроз безопасности и мер контроля (более 600 наименований в каждом каталоге).

Все виды угроз в стандарте BSI разделены на следующие классы:

·Форс мажорные обстоятельства.

·Недостатки организационных мер.

·Ошибки человека.

·Технические неисправности.

·Преднамеренные действия.

Аналогично классифицированы контрмеры:

·Улучшение инфраструктуры;

·Административные контрмеры;

·Процедурные контрмеры;

·Программно технические контрмеры;

·Уменьшение уязвимости коммуникаций; планирование действий в чрезвычайных ситуациях.

Все компоненты рассматриваются и описываются по следующему плану:

)общее описание;

)возможные сценарии угроз безопасности(перечисляются применимые к данной компоненте угрозы из каталога угроз безопасности);

)возможные контрмеры(перечисляются применимые к данной компоненте угрозы из каталога угроз безопасности);

.4 Британский стандарт BS 7799

Британский институт стандартов (BSI) при участии коммерческих организаций, таких как Shell, National Westminster Bank, Midland Bank, Unilever, British Telecommunications, Marks & Spencer, Logica и др. разработал стандарт информационной безопасности, который в1995 г. был принят в качестве национального стандарта BS 7799 управления информационной безопасностью организации вне зависимости от сферы деятельности компании.

В соответствии с этим стандартом любая служба безопасности, IT отдел, руководство компании должны начинать работать согласно общему регламенту. Неважно, идет речь о защите бумажного документооборота или электронных данных. В настоящее время Британский стандарт BS 7799 поддерживается в 27 странах мира, в числе которых страны Британского Содружества, а также, например, Швеция и Нидерланды. В 2000 г. международный институт стандартов ISO на базе британского BS 7799 разработал и выпустил международный стандарт менеджмента безопасности ISO / IEC 17799.

Поэтому сегодня можно утверждать, что BS 7799 и ISO 17799 это один и тот же стандарт, имеющий на сегодняшний день мировое признание и статус международного стандарта ISO.

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

В «»Части 1: Практические рекомендации»» (1995г.) определяются и рассматриваются следующие аспекты ИБ:

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

·Организация защиты.

·Классификация и управление информационными ресурсами.

·Управление персоналом.

·Физическая безопасность.

·Администрирование компьютерных систем и сетей.

·Управление доступом к системам.

·Разработка и сопровождение систем.

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

·Проверка системы на соответствие требованиям ИБ.

«»Часть2: Спецификации системы»»(1998г) рассматривает эти же аспекты с точки зрения сертификации информационной системы на соответствие требованиям стандарта.

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

Дополнительные рекомендации для управления информационной безопасностью содержат руководства Британского института стандартов British Standards Institution (BSI), изданные в период 1995 2003 в виде следующей серии:

·Введение в проблему управления информационной безопасности Information security managment: an introduction.

·Возможности сертификации на требования стандарта BS 7799 Preparing for BS 7799 sertification.

·РуководствоBS 7799 по оценке и управлению рисками Guide to BS 7799 risk assessment and risk management.

·Готовы ли вы к аудиту на требования стандарта BS 7799 Are you ready for a BS 7799 audit?

·Руководство для проведения аудита на требования стандарта BS 7799Guide to BS 7799 auditing.

·Практические рекомендации по управлению безопасностью информационных технологий Code of practice for IT management.

Сегодня общими вопросами управления информационной безопасности компаний и организаций, а также развитием аудита безопасности на требования стандарта BS 7799 занимаются международный комитет Joint Technical Committee ISO/IEC JTC 1 совместно с Британским Институтом Стандартов British Standards Institution (BSI), и в частности служба UKAS (United Kingdom Accredited Service). Названная служба производит аккредитацию организаций на право аудита информационной безопасностью в соответствии со стандартом BS ISO/IEC 7799:2000 (BS 7799 1:2000). Сертификаты, выданные этими органами, признаются во многих странах.

Отметим, что в случае сертификации компании по стандартам ISO 9001 или ISO 9002 стандарт BS ISO/IEC 7799:2000 (BS 7799 1:2000) разрешает совместить сертификацию системы информационной безопасности с сертификацией на соответствие стандартам ISO 9001 или 9002 как на первоначальном этапе, так и при контрольных проверках. Для этого необходимо выполнить условие участия в совмещенной сертификации зарегистрированного аудитора по стандарту BS ISO/IEC 7799:2000 (BS 7799 1:2000). При этом в планах совместного тестирования должны быть четко указаны процедуры проверки системы информационной безопасности, а сертифицирующие органы должны гарантировать тщательность проверки информационной безопасности.

.5 Международный стандарт ISO 17799

Одним из наиболее развитых и широко используемых во всех странах мира стал международный стандарт ISO 17799:

Code of Practice for Information Security Management (Практические рекомендации по управлению безопасностью информации), принятом в 2000 году. ISO 17799 был разработан на основе британского стандарта BS 7799. 17799 может использоваться в качестве критериев для оценки механизмов безопасности организационного уровня, включая административные, процедурные и физические меры защиты.

Практические правила разбиты на следующие10 разделов:

1.Политика безопасности.

2.Организация защиты.

.Классификация ресурсов и их контроль.

.Безопасность персонала.

.Физическая безопасность.

.Администрирование компьютерных систем и вычислительных сетей.

.Управление доступом.

.Разработка и сопровождение информационных систем.

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

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

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

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

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

Ключевыми являются следующие средства контроля:

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

·распределение обязанностей по обеспечению информационной безопасности;

·обучение и подготовка персонала к поддержанию режима информационной безопасности;

·уведомление о случаях нарушения защиты;

·средства защиты от вирусов;

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

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

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

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

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

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

.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.Перекрестный аудит(перекрывающиеся зоны проверки критически важных элементов).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.2 Система CRAMM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выполнение автоматизированных процедур в рамках метода 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 Система КОНДОР

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Современные сканеры способны обнаруживать сотни уязвимостей сетевых ресурсов, предоставляющих те или иные виды сетевых сервисов. Их предшественниками считаются сканеры телефонных номеров (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 <#»»center»»>·Backdoors для обнаружения «»троянских»» программ;

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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