Системы защиты информации в ведущих зарубежных странах (стр. 10 )

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

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

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

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

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

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

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

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

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

Всего в стандарте COBIT выделяется 34 задачи верхнего уровня обработки информации (рис. 7.2).

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

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

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

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

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

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

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

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

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

Представленная на рис 7.3 блок-схема отражает, хотя и не в деталях, ключевые точки проведения аудита ИС с использованием стандарта COBIT. Рассмотрим их подробнее.

На этапе подготовки и подписания исходно-разрешительной документации определяются границы проведения аудита ИБ:

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

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

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

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

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

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

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

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

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

Контрольные вопросы:

1.  С какой целью разрабатывались международные стандарты ИБ?

2.  Назовите основные международные стандарты ИБ.

3.  Какие критерии определяют степень доверия в стандарте «Оранжевая книга»?

4.  Определите назначения и виды классов безопасности в «Оранжевой книге».

5.  Как определяются составляющие ИБ в гармозированных критериях Европейских стран.

6.  Назовите составляющие германского стандарта BSI.

7.  Почему Британский стандарт BS 7799 используется наиболее часто?

8.  В чем отличие применения международных стандартов ISO 15408 и ISO 17799?

9.  Назовите основные этапы проведения аудита ИБ при использовании стандарта CoBiT.

Глава 8

системЫ защиты информации в ведущих мировых компаниях

8.1. Практика компании IBM в области защиты информации

8.2. Практика компании Cisco Systems в разработке сетевой политики безопасности

8.3. Практика компании Microsoft в области информационной безопасности

8.1. Практика компании IBM в области защиты информации

В компании IBM считается что, разработка корпоративных руководящих документов в области безопасности должна начинаться с создания политики информационной безопасности ком­пании. При этом рекомендуется использовать международный стан­дарт ISO 17799:2005 и рассматривать политику безопасности компании как составную часть процесса уп­равления информационными рис­ками (рис. 8.1). Считается, что разра­ботка политики безопасности от­носится к стратегическим задачам ТОР-менеджмента компании, кото­рый способен адекватно оценить стоимость информационных акти­вов компании и принять обоснован­ные решения по защите информа­ции с учетом целей и задач бизнеса [12].

Рис. 8.1. Процесс разработки политики безопасности компании

Компания IBM выделяет следу­ющие основные этапы разработки политики безопасности:

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

2.  Разработка политики безопас­ности, которая описывает меры защиты информационных актинов, адекватных целям и задачам бизнеса.

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

4.  Оценка остаточных информационных рисков и принятие решения о дополнительных инвестициях в средства и меры безопасности. Решение принимает руководство на основе анализа остаточ­ных рисков.

Структура документов безопасности

По мнению специалистов IBM, политика без­опасности компании должна со­держать явный ответ на вопрос: «Что требуется защитить?». Толь­ко после этого можно приступать к созданию эффективной политики информационной безопаснос­ти. При этом политика безопасности является первым стратегичес­ким документом, который необхо­димо создать, и содержит мини­мум технических деталей, являясь настолько статичным (неизменяемым) актом, насколько это воз­можно. Предполагается, что политика безопасности компании будет содержать:

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

§  описание требований по без­опасности, которые включают:

§  соответствие требованиям законодательства и контрактных обязательств;

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

§  предупреждение и обнаруже­ние вирусных атак;

§  планирование непрерывности бизнеса;

§  определение ролей и обязанно­стей по различным аспектам общей программы информа­ционной безопасности;

§  описание требований и про­цесса отчетности по инциден­там, связанным с информаци­онной безопасностью;

§  описание процесса поддержки политики безопасности,

Специалисты по информационной безопасности компании IBM выделяют следу­ющие основные этапы разработки политики безопасности компании:

§  анализ бизнес-стратегии компании и связанные с этим требования по информационной безопас­ности;

§  анализ ИТ-стратегии, текущие проблемы информационной безопасности и требования по ин­формационной безопасности, которые появятся в будущем;

§  создание политики безопасности, взаимно увязанной с бизнес - и ИТ-стратегиями.

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

Рис. 8.2. Структура руководящих документов безопасности

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

В представлении IВМ, полити­ки и стандарты безопасности слу­жат для:

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

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

§  формализации способов защиты, которые должны быть реализованы;

§  определения ожиданий со сторо­ны компании и сотрудников;

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

§  обеспечения юридической под­держки в случае возникновения проблем в области безопасности.

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

Рассмотрим особенно­сти предлагаемого подхода к построению системы безопасности в компании IВМ на конкретном примере.

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

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

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

4.  Практика безопасности опи­сывает способы настройки операционной системы в соответствии с тре­бованиями стандарта безопасности.

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

6.  Устанавливаются дополни­тельные сервисы для контроля выполнения требований политики без­опасности.

8.2. Практика компании Cisco Systems в разработке сетевой политики безопасности

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

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

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

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

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

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

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

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

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

Рекомендуется определить уро­вень риска для каждого из пере­численных устройств: сетевых уст­ройств, устройств мониторинга сети, серверов аутентификации, почтовых серверов, файловых серверов, серверов сете­вых приложений (DNS и DHCP), сервера баз данных (Oracle, MS SQL Server), персональных компьютеров и других устройств.

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

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

Администраторы. Внутренние пользователи, отвечающие за сете­вые ресурсы.

Привилегированные пользователи. Внутренние пользователи с необходимостью высокого уровня до­ступа.

Рядовые пользователи. Внутрен­ние пользователи с обычным уров­нем доступа.

Партнеры. Внешние пользовате­ли с необходимостью доступа к не­которым ресурсам.

Другие. Внешние пользователи или клиенты.

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

Система	Описание	Уровень риска	Типы пользователей
ATM-коммутаторы	Основные сетевые устройства	Высокий	Администраторы для конфигурирования (только персонал поддержки]; все другие для использования в качестве транспорта
Сетевые маршрутизаторы	Сетевые устройства распределения	Высокий	Администраторы для конфигурирования (только персонал поддержки); все другие для использования в качестве транспорта
Коммутаторы доступа	Сетевые устройства доступа	Средний	Администраторы для конфигурирования (только персонал поддержки); все другие для использования в качестве транспорта
ISDN или dial up сервера	Сетевые устройства доступа	Средний	Администраторы для конфигурирования (только персонал поддержки); партнеры и привилегированные пользователи для специального доступа
Межсетевые экраны	Сетевые устройства доступа	Высокий	Администраторы для конфигурирования (только персонал поддержки]; все другие для использования а качестве транспорта
Серверы DNS и DHCP	Сетевые приложения	Средний	Администраторы для конфигурирования; пользователи для повседневного использования
Внешние почтовые серверы	Сетевое приложение	Низкий	Администраторы для конфигурирования; все другие как транспорт для передачи почты между Интернетом и внутренним почтовым сервером
Внутренний почтовый сервер	Сетевое приложение	Средний	Администраторы для конфигурирования; все другие для повседневного использования
Сервер базы данных Oracle	Сетевое приложение	Средний или высокий	Администраторы для конфигурирования; привилегированные пользователи для обновления информации; сотрудники компании для доступа к информации; все остальные имеют частичный доступ к информации

Рис. 8.3. Матрица безопасности Cisco

Определение состава и структуры группы сетевой безопасности.

Специалистами по защите информации компании Cisco Systems рекомендуется создать группу се­тевой безопасности под руковод­ством менеджера по безопасности с представителями из каждой значи­мой бизнес-единицы компании (ми­нимум - из представителей бизнес-единиц развития, исполнения и про­изводства и/или продаж). Члены группы должны хорошо знать поли­тику' безопасности и технические ас­пекты защищаемых систем и сетей. Часто это требует дополнительного обучения сотрудников названной группы. Группа безопасности должна принимать участие в разработке политики безопасности, организа­ции режима информационной безопасности, а также своевременно реагировать на инциденты в облас­ти информационной безопасности компании.

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

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

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

Предупреждение нарушений политики безопасности компании.

Под предупреждением наруше­ний компания Cisco понимает под­тверждение изменений в системах безопасности и мониторинг безопасности сети.

Изменения в системах безопас­ности могут быть определены как изменения в сетевом оборудова­нии, которые могут иметь потен­циальное воздействие на состояние безопасности сети. Политика без­опасности компании должна опре­делять специфические требования конфигурации безопасности, описанные не техническими термина­ми. Другими словами, вместо формулировки «Не разрешены внеш­ние ftp-соединения во внутрен­нюю сеть» лучше воспользоваться определением «Внешние соедине­ния не должны быть способны по­лучать файлы из внутренней сети». При этом желательно стремиться к определению уникальных требо­ваний компании. Использование стандартных шаблонов обеспече­ния безопасности и настроек по умолчанию в подходе компании Cisco настоятельно не рекоменду­ется.

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

§  любые изменения в конфигура­ции межсетевых экранов;

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

§  любые изменения в конфигура­ции SNMP;

§  любые изменения или обновления программного обеспечения, версии которого отличаются от разрешен­ного списка версий программного обеспечения.

Компания Cisco рекомендует сле­довать следующим правилам:

§  регулярно изменять пароли на се­тевых устройствах;

§  ограничить доступ к сетевым уст­ройствам согласно утвержденно­му списку сотрудников;

§  гарантировать, что текущая вер­сия программного обеспечения сетевого и серверного оборудования соответствует требованиям безопасности.

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