Оценка затрат компании на Информационную безопасность

Сергей Петренко

Большинство руководителей служб автоматизации (CIO) и служб информационной безопасности (CISO) отечественных компаний наверняка задавалось вопросами: “Как оценить эффективность планируемой или существующей корпоративной системы защиты информации? Как оценить эффективность инвестиционного бюджета на информационную безопасность (ИБ) компании? В какие сроки окупятся затраты компании на ИБ? Как экономически эффективно планировать и управлять бюджетом компании на ИБ?”. Давайте попробуем найти возможные ответы на эти вопросы.

История вопроса

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

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

Сегодня для оценки эффективности корпоративной системы защиты информации рекомендуется использовать некоторые показатели эффективности, например показатели: совокупной стоимости владения (ТСО), экономической эффективности бизнеса и непрерывности бизнеса(BCP), коэффициенты возврата инвестиций на ИБ (ROI) и другие.

В частности, известная методика совокупной стоимости владения (TCO) была изначально предложена аналитической компанией Gartner Group в конце 80-х годов (1986-1987) для оценки затрат на информационные технологии.
Методика Gartner Group позволяет рассчитать всю расходную часть информационных активов компании, включая прямые и косвенные затраты на аппаратно-программные средства, организационные мероприятия, обучение и повышение квалификации сотрудников компании, реорганизацию, реструктуризацию бизнеса и т. д.

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

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

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


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

Таким образом, методика ТСО Gartner Group позволяет ответить на следующие актуальные вопросы:

Какие ресурсы и денежные средства тратятся на ИБ?

Оптимальны ли затраты на ИБ для бизнеса компании?

Насколько эффективна работа службы ИБ компании по сравнению с другими?

Как эффективно управлять инвестированием в защиту информации?

Какие выбрать направления развития корпоративной системы защиты информации?

Как обосновать бюджет компании на ИБ?

Как доказать эффективность существующей корпоративной системы защиты информации и службы ИБ компании в целом?

Какова оптимальная структура службы ИБ компании?

Как правильно оценить аутсортинговые услуги по сопровождению корпоративной системы защиты информации?

Как оценить эффективность нового проекта в области защиты информации?





Западный опыт на вооружение



В целом методика ТСО компании Gartner Group позволяет:

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

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




оптимизировать инвестиции на ИБ компании с учетом реального значения показателя ТСО.



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

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

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

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

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


Сбор и анализ статистики по структуре прямых (HW/SW, операции, административное управление) и косвенных затрат (на конечных пользователей и простои) проводится, как правило, в течение 12 месяцев. Полученные данные оцениваются по ряду критериев с учетом сравнения с аналогичными компаниями по отрасли.

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

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

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

по заработанной плате сотрудников (Salary and Asset Scalars) c учетом дохода компании, географического положения, типа производства и размещения организации в крупном городе или нет;

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

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

по уровню сложности организации (Complexity Level) с учетом состояния организации конечных пользователей (процент влияния – 40%), технологии SW (40%), технологии HW (20%).





В целом, определение затрат компании на ИБ подразумевает решение следующих трех задач:

оценку текущего уровня ТСО корпоративной системы защиты информации и КИС в целом;

аудит ИБ компании на основе сравнения уровня защищенности компании и рекомендуемого (лучшая мировая практика) уровня ТСО;

формирование целевой модели ТСО.



Рассмотрим каждую из перечисленных задач.

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

существующие компоненты КИС (включая систему защиты информации) и информационные активы компании (серверы, клиентские компьютеры, периферийные устройства, сетевые устройства);

существующие расходы на аппаратные и программные средства защиты информации (расходные материалы, амортизация);

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

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

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



Аудит ИБ компании.По результатам собеседования с TOP-менеджерами компании и проведения инструментальных проверок уровня защищенности организации проводится анализ следующих основных аспектов:

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

организации защиты;

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

управления персоналом;

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

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

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

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

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

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



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


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

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

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

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



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



Пример оценки затрат на ИБ

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

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



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


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



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



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

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



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

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





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

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



Табл. 1. Характеристики базового и повышенного уровня защиты.

Процесс	Задача	Базовый уровень (0)	Высокий уровень (10)
Защита от вирусов	Каким образом распространяются обновления механизма антивирусной защиты?	Ничего не делается или нет информации	Используется автоматическое обновление антивирусного обеспечения
Защита от вирусов	Какая степень защиты от вирусов является допустимой?	Нет механизма защиты от вирусов	Защита от вирусов устанавливается ИС службой и не доступна пользователям для изменений
Защита от вирусов	Какой процент клиентских мест поддерживается серверной антивирусной защитой?	0 %	100 %
Защита от вирусов	Как устраняются последствия вирусных атак (в процентном отношении к числу вирусных событий)?	Пользователь самостоятельно восстанавливает поврежденные файлы и систему, протокол событий не ведется	ИС персонал уведомляется об инциденте, проводятся исследования, и предпринимаются нейтрализующие меры, на местах поддерживается БД вирусных событий
Управление безопасностью	Что делается для гарантии безопасности критичных данных (информация, которая является критичной по отношению к миссии каждого отдельного предприятия)	Ничего не делается	Инструментальные средства шифрования и обеспечения безопасности закупаются у третьей стороны
Управление безопасностью	Что делается для гарантии физической безопасности помещений с целью предотвращения случаев воровства и преступного использования оборудования?	Применяются сигналы тревоги о нарушении безопасности	Используются такие средства безопасности, как смарт-карты или биометрические устройства

<


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



Табл. 2. Статьи расходов базового и повышенного уровня защиты.

Статья затрат	Защита от вирусов	Управление безопасностью
Операции (Operations)
Технические услуги (Technical services)
Решение проблем 2 уровня (Tier II problem resolution)	2,600 %	0,000 %
Решение проблем 3 уровня (Tier III problem resolution)	1,300 %	0,000 %
Администрирование конечных пользователей (User administration, adds and changes)	0,000 %	6,500 %
Установка аппаратного обеспечения (Hardware deployment)	0,000 %	2,600 %
Резервное копирование, архивирование и восстановление (Backup, archiving and recovery)	2,600 %	0,000 %
Планирование и управление процессами (Planning and process management)
Управление системными исследованиями, планированием и продуктами (Systems research, planning and product management)	1,300 %	1,300 %
Безопасность и защита от вирусов (Security and virus protection)	18,200 %	2,600 %
Восстановление деятельности (Business recovery)	19,500 %	0,000 %
Решение проблем 0/1 уровня (Service desk, tier 0/I)
Среднее количество звонков пользователей в месяц (Average number of calls per month)	5,200 %	2,600 %
Административные расходы (Administration)
Финансовые службы и администрация (Finance and administration)
Супервизорское управление (Supervisory management)	1,268 %	0,618 %
Административная поддержка ИС (IS administrative assistance)	0,429 %	0,169 %
Управление активами (Asset management)	0,000 %	5,200 %
Аудит (Audit)	0,000 %	1,300 %
Закупка, снабжение и управление контрактами (Purchasing, procurement and contract management)	0,000 %	2,600 %
Затраты конечных пользователей на поддержку ИС (End User IS Costs)
Количество часов в месяц, затраченных на управление файлами, данными и резервным копированием (Average hours per month spent managing files, data and performing backups)	6,500 %	0,000 %
Количество часов в месяц, затраченных на поиск источника поддержки (Average hours per month spent seeking peer support)	6,500 %	0,000 %
Количество часов в месяц, затраченных на поддержку пользователей друг друга (Average hours per month spent helping others)	6,500 %	0,000 %
Количество часов в месяц, затраченных на самоподдержку пользователей (Average hours per month spent on self support)	6,500 %	2,600 %
Количество незапланированных простоев в месяц (Monthly unplanned downtime hours)	10,400 %	10,400 %

<


В табл. 3 и на рис. 1 показан уровень снижения расходов при переходе на более высокий уровень защищенности КИС (переход с 0-го уровня на 10-й). Поученные данные о снижении ТСО в среднем на 230 тыс. долл. в год позволяют обосновать инвестиции в размере около 600 тыс. долл. на защиту от вирусов. При этом период окупаемости составляет не более 3 лет.



Табл. 3. Уровень снижения расходов при внедрении методов лучшей практики.

Расходы на ИТ	Защита от вирусов -0, Безопасность –0	Защита от вирусов -10, Безопасность -0	Защита от вирусов -0, Безопасность -10	Защита от вирусов -10, Безопасность -10
Совокупная стоимость владения (TCO)	$14,905,090	$14,659,236	$14,796,746	$14,563,990
Расходы на HW/SW	$9,183,334	$9,212,787	$9,211,699	$9,241,232
Расходы на операции ИС	$1,402,287	$1,376,061	$1,394,232	$1,368,450
Административные расходы	$426,758	$425,554	$423,952	$422,748
Расходы на операции конечных пользователей	$2,772,377	$2,636,870	$2,758,898	$2,624,287
Расходы на простои	$1,120,334	$1,007,965	$1,007,965	$907,273

Дадим комментарий к указанным расходам.

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

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

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

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


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

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





Рис. 1. Уровень снижения расходов при внедрении методов лучшей практики.



В табл. 4 и на рис. 2 показан пример расчета ТСО для организаций, обладающих средним уровнем защищенности КИС (5-й уровень).



Табл. 4. Пример расчета ТСО.

Расходы на ИТ	Защита от вирусов -0, безопасность -0	Защита от вирусов -10, безопасность -0	Защита от вирусов -0, безопасность -10	Защита от вирусов -10, безопасность -10
Совокупная стоимость владения (TCO)	$12,326,994	$12,234,237	$12,302,964	$12,215,093
Расходы на HW/SW	$8,884,604	$8,912,435	$8,915,619	$8,943,557
Расходы на операции ИС	$1,016,789	$999,693	$1,011,027	$994,231
Административные расходы	$397,553	$396,525	$395,408	$394,398
Расходы на операции конечных пользователей	$1,611,683	$1,549,384	$1,604,710	$1,542,839
Расходы на простои	$416,365	$376,201	$376,201	$340,068

Рис. 2. Пример расчета ТСО.



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





Заключение



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

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

«Безобидные» цветочки

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

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

Итак, информация теоретически может быть преднамеренно украдена с помощью сети. Естественно, если делать это «в лоб», например отправив на адрес manager@konkurent.com файл «График поставок 2006.xls», то выявить нарушителя фирменной этики не составит абсолютно никакого труда и тогда бы эта проблема вообще не рассматривалась. Но, к сожалению или к счастью, существуют наработанные механизмы сокрытия сущности файла. Например, файл можно зашифровать, причем не просто представив его как бессмысленный набор символов, а зашифровать «отведя удар». Этот метод называется «стеганография», он дает возможность зашифровать в безобидном звуковом или графическом файле определенную информацию. Казалось бы, на адрес Tanya@besplatnayapochta.com отправлен файл «С 8 марта.jpg» - и администратор это заметил. Будучи человеком ответственным, он изучает копию письма, открывает вложенный файл и видит букет ландышей и красивую цифру «8» - все в порядке. А в это время у компании-конкурента уже начался мозговой штурм по изучению графиков поставок в 2006 году.
С этим уже трудно что-либо поделать, единственный выход - никоим образом не дать пользователю инсталлировать программы, не предусмотренные спецификой его работы.

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

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

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

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


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

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

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

Мой офис - моя крепость

Евгений Патий

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

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

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

Сеть защищена, проблемы остались

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

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

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

«Свой» среди своих

Как отмечалось, безопасность может называться таковой, лишь когда она комплексная. Приведем некоторые цифры, свидетельствующие о соотношении сетевых и «внутренних» атак: по данным Федерального бюро расследований США, в 45% случаев утечки конфиденциальных данных виновны свои же сотрудники. То есть сетевая безопасность - полдела, следует приучить к порядку сотрудников, а еще лучше - сделать утечку данных невозможной при всем желании.

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

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

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

Вот такая политика

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

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

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

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

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

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

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

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

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

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

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

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

Электронная почта от юриста Компании или представляющего ее адвоката должна содержать в колонтитуле каждой страницы сообщение: «Защищено адвокатским правом/без разрешения не пересылать».

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

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

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

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

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

В ОК и ОМО применение количественных показателей предусматривается при анализе стойкости функций безопасности ОО, реализованных вероятностными и/или перестановочными механизмами.

В процессе анализа оценщик определяет минимальный потенциал нападения, требуемый нарушителю, чтобы осуществить нападение, и приходит к заключению относительно возможностей ОО противостоять нападению. В Таб. 1 демонстрируются и далее описываются взаимосвязи между анализом СФБ и потенциалом нападения.

Таблица 1. Стойкость функции безопасности и потенциал нападения

>

Уровень СФБ

Адекватная защита от нарушителя с потенциалом нападения:

Недостаточная защита от нарушителя с потенциалом нападения:

высокая СФБ	высокий	Не применимо — успешное нападение за пределами практически возможного
средняя СФБ	умеренный	высокий
базовая СФБ	низкий	умеренный

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

Потенциал нападения является функцией от мотивации, компетентности и ресурсов нарушителя.

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

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

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

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

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

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

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

"Отсутствие информации" об ОО, кроме его назначения;"Общедоступная информация" об ОО (например, полученная из руководства пользователя);"Чувствительная информация" об ОО (например, сведения о внутреннем содержании проекта).

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



Фактор "Аппаратные средства/ программное обеспечение ИТ или другое оборудование" указывает на оборудование, которое требуется для идентификации или использования уязвимости.

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

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

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

Таблица 2. Вычисление потенциала нападения


>

Название фактора

Диапазон

Значение при идентификации уязвимости

Значение при использовании уязвимости

Затрачиваемое время	< 0.5 часа	0	0
>	< 1 день	2	3
>	< 1 месяц	3	5
>	> 1 месяц	5	8
>	Не практично	*	*
Компетентность	Непрофессионал	0	0
>	Профессионал	2	2
>	Эксперт	5	4
Знание ОО	Отсутствие информации	0	0
>	Общедоступная информация	2	2
>	Чувствительная информация	5	4
Доступ к ОО	< 0.5 часа или не обнаруживаемый доступ	0	0
>	< 1 день	2	4
>	< 1 месяц	3	6
>	> 1 месяц	4	9
>	Не практично	*	*
Оборудование	Отсутствует	0	0
>	Стандартное	1	2
>	Специализированное	3	4
>	Заказное	5	6
* Означает, что нападение невозможно в пределах тех временных рамок, которые были бы приемлемы для нарушителя. Любое значение "*" указывает на противостояние нарушителю с высоким потенциалом нападения.

При определении потенциала нападения для данной уязвимости из каждого столбца (столбцы 2 и 3 Таб. 2) для каждого фактора следует выбрать определенное значение (10 значений). При выборе значений должна учитываться предопределенная среда ОО. Выбранные 10 значений суммируются, давая итоговое значение. Это значение затем сверяется с Таб. 3 для определения рейтинга уязвимости и соответственно по Таб. 1 — уровня СФБ. Полученный уровень стойкости функции безопасности говорит о том, нарушителю с каким потенциалом противостоит ОО.

Таблица 3. Рейтинг уязвимостей


>

Диапазон значений

ОО противостоит нарушителю с потенциалом нападения:

< 10	Нет рейтинга
10-17	Низкий
18-24	Умеренный
> 25	Высокий

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

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

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

История вопросаСуществующие версии

В 1990 году под эгидой Международной организации по стандартизации (ИСО) и при содействии в дальнейшем государственных организаций США, Канады, Великобритании, Франции, Германии и Нидерландов были развернуты работы по созданию международного стандарта (исторически сложившееся название — Общие критерии) в области оценки безопасности информационных технологий (ИТ). Разработка этого стандарта преследовала следующие основные цели:

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

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

Официальный текст международного стандарта ISO/IEC 15408 [1] [2] [3] издан 1 декабря 1999 года. Изменения, внесенные в стандарт на завершающей стадии его принятия, учтены в версии 2.1 Общих критериев (ОК), идентичной стандарту по содержанию. В 2002 году на основе аутентичного текста ISO/IEC 15408 был принят российский стандарт ГОСТ Р ИСО/МЭК 15408-2002 "Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий" [4] [5] [6].

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

Руководство по разработке профилей защиты и заданий по безопасности [7];Процедуры регистрации профилей защиты [8];Общая методология оценки безопасности информационных технологий [9] [10].

Что касается первых двух документов, то их аналоги уже есть в России в виде руководящих документов, одобренных в январе 2004 года коллегией Гостехкомиссии России. Настоящая статья посвящена последнему из перечисленных (но далеко не последнему по значению) документу — "Общая методология оценки безопасности информационных технологий" (ОМО).

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

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

Несколько слов о взаимном признании оценок. В 1998 году правительственными организациями Канады, Франции, Германии, Великобритании и США было подписано соглашение о взаимном признании оценок (The International Mutual Recognition Arrangement — MRA), полученных на основе Общих критериев. В соответствии с этим Соглашением стороны намеревались признавать сертификаты на продукты и системы ИТ, полученные в странах, присоединившихся к Соглашению, если они получены на основе применения Общих критериев и выданы организациями, удовлетворяющими требованиям Соглашения. Установленные в MRA правила позволяли присоединиться к Соглашению как в виде участника, только признающего сертификаты, выданные в соответствии с ОК, так и в виде участника, выдающего эти сертификаты.

В мае 2000 года представителями уже четырнадцати стран (Канады, Франции, Германии, Великобритании, США, Нидерландов, Италии, Греции, Испании, Швеции, Норвегии, Финляндии, Австралии и Новой Зеландии) было подписано более универсальное (по сравнению с MRA) соглашение CCRA (Arrangement of the Recognition of Common Criteria Certificates in the field of Information Technology Security). Соглашение CCRA значительно расширяет возможности присоединения новых стран-участниц. В 2001 году к соглашению CCRA присоединился Израиль, в 2002 году — Австрия, в 2003 году — Турция, Венгрия и Япония.

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

Литература

[1] Information technology — Security techniques — Evaluation Criteria for IT Security. Part 1: Introduction and general model. ISO/IEC 15408-1:1999

[2] Information technology — Security techniques — Evaluation Criteria for IT Security. Part 2: Security functional requirements. ISO/IEC 15408-2:1999

[3] Information technology — Security techniques — Evaluation Criteria for IT Security. Part 3: Security assurance requirements. ISO/IEC 15408-3:1999

[4] ГОСТ Р ИСО/МЭК 15408-1-2002. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 1: Введение и общая модель.

[5] ГОСТ Р ИСО/МЭК 15408-2-2002. Методы и сред-ства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 2: Функциональные требования безопасности.

[6] ГОСТ Р ИСО/МЭК 15408-3-2002. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий. Часть 3: Требования доверия к безопасности.

[7] Guide for Production of Protection Profiles and Security Targets. ISO/JTC1/SC27/N2449. DRAFT v0.9, January 2000

[8] Information technology — Security techniques — Protection Profile registration procedures. ISO/IEC 15292:2001.

[9] Common Evaluation Methodology for Information Technology Security Evaluation. Part 1: Introduction and general model, version 0.6, 19 January 1997

[10] Common Evaluation Methodology for Information Technology Security Evaluation. Part 2: Evaluation Methodology, version 1.0, August 1999

[11] Evaluation Methodology for the Common Criteria for Information Technology Security Evaluation, version 1.1a, 19 April 2002

[12] Руководящий документ — Безопасность информационных технологий — Критерии оценки безопасности информационных технологий — Часть 1: Введение и общая модель -- Гостехкомиссия России, 2002

[13] Руководящий документ — Безопасность информационных технологий — Критерии оценки безопасности информационных технологий — Часть 2: Функциональные требования безопасности -- Гостехкомиссия России, 2002

[14] Руководящий документ — Безопасность информационных технологий — Критерии оценки безопасности информационных технологий — Часть 3: Требования доверия к безопасности -- Гостехкомиссия России, 2002

[15] Руководящий документ — Безопасность информационных технологий — Общая методология оценки безопасности информационных технологий (проект) -- Гостехкомиссия России, 2004

[16] Безопасность информационных технологий — Типовая методика оценки безопасности профилей защиты и заданий по безопасности (проект) -- Гостехкомиссия России, 2004

Общая модель оценки

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

Рисунок 2. Общая модель оценки

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

Заявитель инициирует оценку, то есть является заказчиком оценки и отвечает за обеспечение оценщика свидетельствами оценки.

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

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

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

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

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

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

Оформление результатов оценки

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

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

Особенности выполнения количественных оценок

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

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

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

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

В заключение рассмотрим перспективы развития ОМО. История ОМО неразрывно связана с историей самих Общих критериев

(Рис. 7). В настоящее время официальными документами Соглашения CCRA являются версия 2.1 ОК и версия 1.0 ОМО. В то же время, несмотря на то, что ОК уже давно (с 1999 года) нашли свое воплощение в стандарте ИСО, ОМО стала рассматриваться в качестве возможного документа (технического отчета) этой международной организации только два года назад.

Рисунок 7. Перспективы развития ОК и ОМО

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

Новыми же официальными документами CCRA станут, скорее всего, ОК версии 2.2 и ОМО версии 1.2, которые, по сути, будут технической редакцией ОК версии 2.1 и ОМО версии 1.0 соответственно. В них войдут итоговые интерпретации (принятые CCRA изменения и дополнения в текущие версии ОК и ОМО), но ОМО так и останется структурированной по ОУД.

Появление промежуточных версий ОК (версия 2.3) и ОМО (версия 1.3), уже структурированной не по ОУД, ожидается в конце 2004 года. Но эти документы также, скорее всего, не станут официальными документами CCRA, будут подвергнуты апробации и дальнейшей доработке и ориентировочно в 2006 году получат новый (уже единый) номер версии — 3.0. Именно ОК/ОМО версии 3.0 планируется как основа нового издания стандарта ИСО, а также как официальные документы Соглашения CCRA.

Что касается России, то в настоящее время подготовлен проект РД Гостехкомиссии России "Общая методология оценки безопасности информационных технологий" [15] и проект "Типовой методики оценки профилей защиты и заданий по безопасности" [16].

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

Подготовка СП

СП предоставляют оценщику механизм для запроса разъяснений (например, от органа оценки о применении требований) или для определения проблемы по одному из аспектов оценки (например, запрос на корректировку ЗБ, направляемый заявителю оценки).

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

Оформляя СП, оценщик должен привести в нем следующую информацию:

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

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

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

Подготовка ТОО

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

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

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

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

В ОМО предусмотрены две разновидности ТОО:

ТОО по результатам оценки ПЗ;ТОО по результатам оценки ОО.

Рассмотрим их подробнее.

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

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

В ОМО различаются три взаимоисключающих вида заключения:

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

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

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

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

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

Применение Общей методологии оценки безопасности информационных технологий в России

Рассматривая перспективы вступления России в CCRA, следует отметить, что данное соглашение устанавливает для своих участников необходимость проведения работ в направлении единообразной интерпретации ОК и ОМО. Результатом такой работы в России стал выпуск ГОСТ Р ИСО/МЭК 15408-2002 [4] [5] [6] и соответствующего РД Гостехкомиссии России [12] [13]

[14]. Что касается ОМО, то работа по подготовке российского аналога в настоящее время ведется (и весьма активно) специалистами ООО "Центр безопасности информации", Центра "Атомзащитаинформ" и ЦНИИАТОМИНФОРМ Минатома России при поддержке экспертов международной рабочей группы по Общим критериям.

С принятием в России ГОСТ P ИСО/МЭК 15408 (идентичного международному стандарту ISO/IEC 15408) появилась возможность и настоятельная необходимость его использования для оценки безопасности продуктов и систем ИТ.

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

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

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

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

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

Разработанные специалистами ЦБИ типовые методики сертификационных испытаний по Общим критериям, которые уже использовались при сертификации отечественного межсетевого экрана "Z-2" (разработчик — ЗАО "Инфосистемы Джет"), операционной системы Microsoftndows Professional Service Pack 1a (разработчик — корпорация Microsoft), межсетевого экрана Symantec(TM) Enterprice Firewall, Version 7.0.4 (разработчик — корпорация Symsntec), будут использоваться и в дальнейшем при сертификации других продуктов и систем ИТ.

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

Рассмотрим пример анализа СФБ для гипотетического механизма цифрового пароля.

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

Рисунок 3. Функциональные требования безопасности как источник для расчета стойкости функции безопасности

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

Число возможных значений цифровых паролей рассчитывается следующим образом:

Допуская самый плохой вариант сценария, когда пользователь выбирает число, состоящее только из четырех цифр, число перестановок цифрового пароля (предполагая, что каждая цифра уникальна) равно: 7*8*9*10 = 5040Число возможных увеличивающихся рядов — семь, как и число убывающих рядов. После отбрасывания этих рядов число возможных значений цифровых паролей равно: 5040 — 14 = 5026

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

В среднем нарушитель должен был бы ввести 2513 цифровых комбинаций до ввода правильного цифрового пароля. Как результат, в среднем, успешное нападение произошло бы чуть меньше, чем за
2513 мин / (60 мин/час) ~ 42 часа
Используя подход, описанный в п. 3.2.1, следует выбирать значения факторов при идентификации, минимальные из каждой категории (все 0), так как существование уязвимости в рассматриваемой функции очевидно. Основываясь на приведенных выше вычислениях, для непрофессионала является возможным нанести поражение механизму в пределах дней (при получении доступа к ОО) без использования какого-либо оборудования и без знания ОО, что в соответствии с таблицей 2 (для использования уязвимостей) дает значение 11. Получив результирующую сумму — 11, потенциал нападения, требуемый для осуществления успешной атаки, определяется, по меньшей мере, как умеренный.
Поскольку механизм цифрового пароля является стойким к нарушителю с низким потенциалом, то этот механизм цифрового пароля соответствует уровню "базовая СФБ" (Таб. 1).

Существующие версии Общей методологии оценки безопасности информационных технологий

Выход первой версии ОМО датирован августом 1999 года. Соответствующий документ носит название "Common Methodology for Information Technology Security Evaluation" и состоит из двух частей:

Часть 1: Introduction and General Model (Часть 1. Введение и общая модель) [9];Часть 2: Evaluation Methodology (Часть 2. Методология оценки) [10].

Отличительной особенностью ОМО версии 1.0 (Часть 2 ОМО) является то, что структуризация действий и шагов оценивания проведена по оценочным уровням доверия (ОУД1-ОУД4).

В то же время отметим, что в ПЗ/ЗБ для продуктов и систем ИТ редко когда какой-либо ОУД используется в "чистом" виде (без компонентов доверия, его дополняющих). Как правило, используется именно ОУД усиленный (то есть некоторый ОУД+), для оценки по которому до конца непонятно, как использовать часть 2 ОМО, то есть как из нее "вырывать" отдельные составляющие (соответствующие дополнительным по отношению к конкретному ОУД компонентам доверия) и как эти составляющие интегрировать в ту часть ОМО, которая относится к конкретному ОУД.

Часть 1 рассматриваемой версии ОМО появилась намного раньше, чем часть 2, а именно в 1997 году, то есть даже раньше, чем версия 2.0 ОК, положенная в основу международного стандарта ISO/IEC 15408. Это привело к тому, что между частями ОМО есть некоторые противоречия, которые следует разрешать в пользу части 2 ОМО и этой частью необходимо руководствоваться. Разработчиками ОМО предполагалось актуализировать часть 1 ОМО и объединить ее с частью 2 ОМО.

В апреле 2002 года вышла ОМО версии 1.1а (не в полном объеме) под названием "Evaluation Methodology for the Common Criteria for Information Technology Security Evaluation".

Новая версия ОМО претерпела ряд существенных изменений:

В отличие от предыдущей, указанная версия ОМО [11] не разделена на две части.Структуризация действий и шагов оценивания проведена не по ОУД, а по видам деятельности, соответствующим классам доверия ОК.Существенной переработке в настоящее время подвергаются следующие главы ОМО:

глава 3 "Оценка ПЗ";глава 4 "Оценка ЗБ";глава 12 "Вид деятельности AVA" (анализ уязвимостей).Добавлены следующие главы:



глава 5 "Пакеты доверия";

глава 13 "Поддержка доверия" (AMA).5. Добавлен подраздел 10.4 "Оценка устранения недостатков" ( компоненты семейства ALC_FLR не входят ни в один ОУД и могут быть использованы для дополнения предопределенных ОУД).

ОМО, как и ОК, является динамично развивающимся документом. В версии 1.1а структура ОМО изменена таким образом, чтобы впоследствии охватить все компоненты доверия из части 3 ОК. В рассматриваемом документе учтены также все относящиеся к ОМО интерпретации, выпущенные после выхода версии 1.0 ОМО.

Разработчики ОМО при ее создании руководствовались следующими принципами:

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

Эти принципы нашли отражение при описании представленных в методологии видов деятельности по оценке.

Между структурой ОК (класс — семейство — компонент — элемент) и структурой ОМО (вид деятельности — подвид деятельности — действие — шаг оценивания) была установлена прямая взаимосвязь. Рис. 1 иллюстрирует соответствие между такими конструкциями ОК, как классы, компоненты и элементы действий оценщика, и рассматриваемыми в ОМО видами деятельности, подвидами деятельности и действиями.


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

Рисунок 1. Соотношение структур ОК и ОМО



В ОМО термин "Вид деятельности" ("activity") используется для описания применения класса доверия из части 3 ОК.

Для описания применения компонента доверия из части 3 ОК используется термин "Подвид деятельности" ("sub-activity"). Заметим, что семейства доверия прямо не рассматриваются в ОМО, поскольку при проведении оценки всегда используется только один компонент доверия из применяемого семейства.

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

Термин "Шаг оценивания" ("work unit") описывает неразделимый фрагмент работы по оценке. Каждое действие в ОМО включает один или несколько шагов оценивания, которые сгруппированы по элементам содержания и представления или действий разработчика соответствующего компонента из части 3 ОК. Шаги оценивания представлены в ОМО в том же порядке, что и элементы ОК, из которых они следуют. Шаги оценивания содержат обязательные действия, которые оценщик должен выполнить, чтобы прийти к заключению.

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

ОМО разбита на следующие главы:

Глава 1 "Введение" описывает цели, структуру, соглашения и терминологию документа.Глава 2 "Процесс оценки и соответствующие задачи" описывает задачи, которые относятся ко всем видам деятельности по оценке (задачи получения исходных данных для оценки и оформления результатов оценки).Глава 3 "Оценка ПЗ" описывает методологию оценки ПЗ, основанную на классе APE части 3 ОК.Глава 4 "Оценка ЗБ" описывает методологию оценки ЗБ, основанную на классе ASE части 3 ОК.


В ОМО не предусмотрено отдельного документа для оформления результатов оценки ЗБ.Глава 5 "Пакеты доверия" представляет обзор выбора и/или конструирования пакетов компонентов доверия.Главы 6-13 описывают методологию оценивания по классам и компонентам, приведенным в ОК. Глава 14 "Общие указания по оценке" содержит те общие правила оценки (при выборке, анализе непротиворечивости, учете зависимостей, посещении объектов), которые применяются при оценивании более чем по одному классу доверия из ОК.Приложение A "Глоссарий" содержит сокращения, а также словарь терминов и ссылки, используемые в ОМО.Приложение Б "Сфера ответственности системы оценки" содержит перечень вопросов, которые оставлены для решения в системах оценки.Приложение В "Границы ОО" представляет описание терминов, применяемых для идентификации сущности, подлежащей оценке.Приложение Г "Запрос на интерпретацию ОМО" содержит краткое изложение способа подачи запроса на интерпретацию ОМО.

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

Технический отчет об оценке профиля

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

Давайте дружить семьями

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

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

отправив письмо используемым вами почтовым клиентом;

открыв используемым вами браузером веб-страницу на специальном сайте и передав туда информацию;

отправив данные через IRC, ICQ или другие средства связи.

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

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

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

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

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

Firewall - не панацея. Защита должна быть комплексной!

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

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

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

В связи с тем что почтовые черви распространяются чрез электронную почту, практически все межсетевые экраны оказываются неэффективны. Откуда firewall'у знать: пользователь ли отправляет письмо - или же это червь рассылает себя. Некоторые администраторы почтовых серверов в борьбе с вирусами применяют самые кардинальные меры - почтовый сервер не пропускает файлы, имеющие запускные расширения (EXE, COM, PIF, BAT, CMD, SCR и т.п.). Но ведь это тоже не выход. Так, сетевой червь I-Worm.Lentin отправляет свои копии в ZIP-архиве (неужели теперь и архивы резать будем?).

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

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

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



защитой от DoS атак;

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

разграничением доступа приложений к ресурсам сети;

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

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

детектированием backdoor-программ (приложений для удаленного доступа) использующих прямое соединение;

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

Не антивирусом единым

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

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

поиск известных вирусов по присутствующим в антивирусных базах вирусным сигнатурам;

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

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

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

Кардинально отличается от сигнатурного метода метод эвристического поиска. Эвристические анализаторы различных продуктов могут работать по-разному.
Фактически каждый из них - это know- how той или иной компании. Но вся работа эвристических анализаторов сводится к одному: поиск последовательностей кода (исполняемых команд), характерных для того или иного типа вирусов.

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

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

Именно из-за описанных выше проблем эвристические анализаторы способны обнаруживать далеко не все вредоносные программы. Для некоторых типов вирусов этот показатель близок к ста процентам - для других же может колебаться в пределах 30-60% (для троянских программ этот показатель всегда ниже, чем для вирусов). Кроме того, эвристические анализаторы могут иногда ошибаться и обзывать вирусами вполне мирные и привычные нам программы - это называется ложным срабатыванием.

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

Описанные достоинства и недостатки определяют возможности антивирусных продуктов:



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

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

нейтрализация/изолирование зараженных и подозрительных файлов;

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

Один в поле не воин: межсетевые экраны и антивирусы - братья навеки!

Олег Сыч,

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

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

Аудит программного обеспечения

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

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

Безопасность систем с открытым кодом

Криспин Кован

07.08.2003

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

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

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

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

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

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

Блокираторы поведения

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

Openwall. По существу, — заплатка для ядра Linux, усиливающая защиту ОС и включающая три блокиратора поведения.

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

Две последние возможности реализованы в интерфейсе LSM в виде модуля OWLSM. OWLSM, получивший свое название от аббревиатуры Openwall (OWL) и LSM, поддерживает правило «никаких ptrace для процессов суперпользователя», что защищает от ошибок при обработке ptrace в ядре Linux.

Libsafe. Библиотека, созданная для стандартных функций glibc, проверяет корректность аргументов, предотвращая использование функций glibc для причинения вреда вызывающей программе [19]. Libsafe 2.0 может предотвращать использование дефектов, приводящих к переполнению буфера и некорректному использованию строки формата оператора printf, за счет прекращения выполнения функции, если она пытается переписать запись активации, которая вызывает функцию. Основное ограничение состоит в том, что данный механизм не действует, если программы скомпилированы с ключом fomit-frame-pointer (его часто применяют, чтобы предоставить компилятору GCC/x86 возможность зарезервировать еще один регистр).

RaceGuard. Атаки с использованием временных файлов организуются в тех случаях, когда хакер пытается использовать промежуток времени при создании файла с помощью привилегированных программ (setuid). При обычных операциях создания временных файлов всегда есть промежуток времени между моментом, когда программа проверяет существование файла, и моментом, когда она записывает данные в этот файл [20]. RaceGuard защищает от такой формы атаки, максимально сокращая время между проверкой существования и доступом к файлу, тем самым не позволяя хакеру «проскользнуть» между операциями чтения и записи [21]. Эффективный доступ реализуется за счет использования так называемой «оптимистической блокировки» (optimistic locking): разрешаются обе операции доступа, но вторая операция записи блокируется, если она фантастическим образом указывает на другой файл, а не на тот, который был использован при первом обращении [22]. RaceGuard реализуют в интерфейсе LSM.

Systrace. Гибридный инструментарий, объединяющий средства контроля доступа и блокиратор поведения для OpenBSD и NetBSD, как и SubDomain, позволяет системным администраторам указывать, к каким файлам может получить доступ каждая из программ. Кроме того, позволяет определять, какой системный вызов может выполнять программа, тем самым давая возможность реализовать определенный вид блокировки действий.

Динамические отладчики

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

Sharefuzz. Fuzz (дословно «шпик») — термин, обозначающий проверку граничных условий программы за счет передачи входных значений, которые с большой вероятностью приведут к сбою (например, вызовут переполнение буфера и тем самым позволят обнаружить уязвимые места в строках формата printf). Идея заключается в том, чтобы передать входные значения, состоящие из необычно длинных строк или строк, содержащих %n, а затем проанализировать дамп ядра для этой программы.

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

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

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

EnGarde

EnGarde — коммерческий вариант Linux, дополненный элементами контроля доступа LIDS.

FormatGuard

FormatGuard аналогичен StackGuard: он выявляет и прекращает работу программы в случае использования уязвимых мест в строке формата printf [12]. FormatGuard был первым инструментарием, созданным для предотвращения использования уязвимых мест в строке формата оператора printf. В FormatGuard применяются макросы препроцессора CPP для подсчета аргументов времени компиляции и вокруг функций printf формируются оболочки времени исполнения, которые устанавливают соответствие между предполагаемым числом аргументов в строке формата и реально переданным числом аргументов. FormatGuard предлагается в виде вариата glibc на условиях LGPL.

Immunix

Чтобы оставаться адекватным самым последним версиям программ, Immunix не применяет никаких средств аудита исходных текстов. Вместо этого он компилирует эти тексты вместе со средствами предотвращения использования уязвимых мест (Stack-Guard и FormatGuard), тем самым не давая хакерам возможность проникнуть в систему через большинство уязвимых мест. Хотя многие компоненты Immunix распространяются в открытых кодах, система целиком является коммерческой.

Интегрированные системы

Рассмотрим три разработки, которые интегрируют некоторые из рассмотренных средств.

Контроль доступа

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

Приведение типов и DTE. Реализует идею разделения пользователей по доменам, разделения файлов по типам и управление доступом, путем указания, какие домены к какому типу могут обращаться [15]. DTE (Domain and Type Enforcement) — усовершенствование этой концепции [16]. Серж Хеллин разрабатывает свободно распространяемую версию DTE, отражаемую на интерфейс LSM.

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

SELinux. Создан на основе приведения типов в компании Secure Computing. Также опирается на ядро Flask, разработанное в университете штата Юта и сейчас поддерживаемое NAI при финансировании Агентства национальной безопасности США. SELinux включает в себя широкий спектр функций для управления доступом и контроля безопасности, в том числе Role-Based Access Control [17]. SELinux играет определяющую роль в проекте LSM; распространяется исключительно как модуль LSM.

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

В отличие от систем DTE и SELinux, в SubDomain выразительность была принесена в жертву простоте.
SELinux позволяет формулировать более «хитроумные» правила, чем SubDomain, и служит для решения сложных задач контроля многопользовательского доступа. С другой стороны, SubDomain проще в управлении и быстрее подготавливается к работе. Так, сервер Immunix (в том числе SubDomain) удалось добавить в контекст Defcon Capture-the-Flag [19], в котором в течение 10 часов формировались профили SubDomain для самых разных и имеющих множество дефектов программ. Защита полученной системы ни разу не была нарушена. Существует реализация SubDomain в интерфейсе LSM.

Linux Intrusion Detection System. Система, первоначально разработанная как модель доступа, призванная не допустить модификацию критически важных файлов с помощью любого процесса, если tty, управляющий этим процессом, не является физической консолью. Впоследствии LIDS архитектуру расширили, позволив работать с конкретными файлами строго определенным программам, аналогично тому, как это реализовано в SubDomain. Существует реализация LIDS в интерфейсе LSM.

Linux Security Modules

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

Проект Linux Security Modules (LSM) [13] призван решить эту проблему за счет создания единого модульного интерфейса в ядре Linux, чтобы пользователи могли загружать усовершенствованные системы контроля доступа в стандартных ядрах Linux; после чего конечные пользователи могли бы адаптировать эти системы к своим требованиям. Для этого в рамках LSM необходимо добиться следующего.

Стать приемлемым для широкого круга пользователей Linux. Линус Торвальдс и его коллеги выступают как своего рода организация стандартизации ядра Linux. Добавление возможности наподобие LSM требует их одобрения. Для этого, в свою очередь, необходимо, чтобы влияние LSM на ядро было минимальным (т.е. незначительная дополнительная нагрузка и незначительные изменения в исходных текстах). LSM с самого начала разрабатывались с учетом этих требований. Подходить для разнообразных элементов управления доступом. Действительно полезный инструмент должен допускать реализацию в виде модулей LSM широкого круга моделей защиты. Проще всего это сделать, предложив выразительный API-интерфейс. К сожалению, это прямо противоречит требованию о минимальном вмешательстве. Поэтому LSM решает данную задачу за счет объединения и унификации нескольких API.

В июне 2002 года Торвальдс согласился добавить LSM в Linux 2.5 (разрабатываемая сейчас версия ядра), так что вполне вероятно, что она станет стандартной возможностью в Linux 2.6.

OpenBSD

Идея, лежащая в основе OpenBSD, состоит в том, чтобы использовать наилучшие практические решения для организации защиты. Все исходные тексты подвергаются тщательной проверке вручную. При установке по умолчанию разрешается лишь небольшое число сетевых служб, тем самым минимизируется потенциальная уязвимость системы, возникающая из-за случайных программных дефектов. OpenBSD также включает в себя вызов jail(), аналогичный широко распространенному механизму изоляции chroot(). Совсем недавно в OpenBSD была добавлена Systrace. Также в OpenBSD входит OpenSSH, свободно распространяемая версия популярного протокола SSH. Разработчики OpenBSD модернизировали OpenSSH, чтобы он мог использовать «разделение привилегий», что позволяет свести к минимуму уязвимость системы из-за ошибок в демоне SSH. Распространяется в открытых кодах.

Openwall Linux

По своей идеологии напоминает OpenBSD (контроль корректности исходных текстов и минимальные усилия по установке и конфигурированию), но ориентирован на Linux, а не на BSD. Использует блокираторы поведения Openwall.

Открытые вопросы

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

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

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

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

ProPolice

ProPolice — программа, аналогичная StackGuard, но обладающая несколькими дополнительными возможностями.

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

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

Sardonix

Цель проекта Sardonix состояла в решении социальных проблем, связанных с попытками убедить специалистов в необходимости проверять корректность кода и регистрировать свои результаты. В таблице 1 представлены некоторые статистические и динамические инструменты аудита программного обеспечения.

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

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

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

Microsoft предложила возможность StackGuard для компилятора Visual C++ 7.0 [23]. В принципе, это имеет то же значение для укрепления защиты, что и свободно распространяемые системы, но на практике воспользоваться этим механизмом могут только распространители кода, поскольку никто другой не имеет исходных текстов, которые можно использовать для компиляции.

Средства управления действиями

Ряд производителей предлагает коммерческие инструменты защиты, рекламируя свои продукты как средства, «предотвращающие проникновение на узлы сети». Среди них — компания Entercept (блокиратор поведения, который предотвращает использование ряда известных уязвимых мест) и Okena (система контроля доступа на основе профилей, аналогичная Systrace). В данном случае преимущества систем с открытым кодом проявляются довольно слабо: возможность чтения исходных текстов приложения может в чем-то помочь при создании профиля для приложения, но определяющего значения не имеет. Главное преимущество открытых исходных текстов заключается в том, что исследователи и разработчики могут достаточно просто добавить такого рода возможности к операционным системам с открытым кодом.

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

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

Литература

E.S. Raymond, The Cathedral & the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary, O'Reilly & Assoc., 1999. K. Brown, Opening the Open Source Debate, Alexis de Tocqueville Inst., 2002; www.adti.net/cgi-local/SoftCart.100.exe/online-store/scstore/p- brown_% 1.html?L+scstore+llfs8476ff0a810a+1042027622. D.
Wagner et al., " A First Step Towards Automated Detection of Buffer Overrun Vulnerabilities", Network and Distributed System Security, 2000; www.isoc.org. X. Zhang, A. Edwards, T. Jaeger, "Using CQUAL for Static Analysis of Authorization Hook Placement", Usenix Security Symp., Usenix Assoc., 2002. U. Shankar et al., "Automated Detection of Format-String Vulnerabilities", Usenix Security Symp., Usenix Assoc., 2001. H. Chen, D. Wagner, "MOPS: An Infrastructure for Examining Security Properties of Software", Proc. ACM Conf. Computer and Communications Security, ACM Press, 2002. J. Viega et al., "ITS4: A Static Vulnerability Scanner for C and C++ Code", Ann. Computer Security Applications Conf. (ACSAC), Applied Computer Security Assoc., 2000. C. Cowan, "Format Bugs in Windows Code", Vulndev mailing list, 10 Sept. 2000; www.securityfocus.com/archive/82/81455. S. Shankland, "Unix, Linux Computers Vulnerable to Damaging New Attacks", Cnet, 7 Sept. 2000. C. Cowan et al., "StackGuard: Automatic Adaptive Detection and Prevention of Buffer-Overflow Attacks", 7th Usenix Security Conf., Usenix Assoc., 1998. "Smashing the Stack for Fun and Profit", Phrack, vol. 7, Nov. 1996. C. Cowan et al., "FormatGuard: Automatic Protection from printf Format String Vulnerabilities", Usenix Security Symp., Usenix Assoc., 2001. C. Wright et al., "Linux Security Modules: General Security Support for the Linux Kernel", Usenix Security Symp., Usenix Assoc., 2002. J.H. Saltzer, M.D. Schroeder, "The Protection of Information in Computer Systems", Proc. IEEE, vol. 63, Nov. 1975. W.E. Bobert, R.Y. Kain, "A Practical Alternative to Hierarchical Integrity Policies", Proc. 8th Nat'l Computer Security Conf., Nat'l Inst. Standards and Technology, 1985. L. Badger et al., "Practical Domain and Type Enforcement for Unix", Proc. IEEE Symp. Security and Privacy, IEEE Press, 1995. D.F.


Ferraiolo, R. Kuhn, "Role-Based Access Control", Proc. 15th Nat'l Computer Security Conf., Nat' l Inst. Standards and Technology, 1992. C. Cowan et al., "SubDomain: Parsimonious Server Security", Usenix 14th Systems Administration Conf. (LISA), Usenix Assoc., 2000. A. Baratloo, N. Singh, T. Tsai, "Transparent Run-Time Defense Against Stack Smashing Attacks", 2000, Usenix Ann. Technical Conf., Usenix Assoc., 2000. M. Bishop, M. Digler, "Checking for Race Conditions in File Accesses", Computing Systems, vol. 9, Spring 1996. C. Cowan et al., "RaceGuard: Kernel Protection from Temporary File Race Vulnerabilities", Usenix Security, Symp., Usenix Assoc., 2001. C. Cowan, H. Lutfiyya, "A Wait-Free Algorithm for Optimistic Programming: HOPE Realized", 16th Int'l Conf. Distributed Computing Systems (ICDCS'96), IEEE Press, 1996. B. Bray, How Visual C++ .Net Can Prevent Buffer Overruns, Microsoft, 2001.

Криспин Кован (crispin@wirex.com) — директор по науке компании WireX Communications. Специализируется на создании решений, позволяющих усилить защиту информационных систем.

Crispin Cowan, Software Security of Open-Source Systems. IEEE Security & Privacy, January-February 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.

StackGuard

StackGuard, по-видимому, был первым инструментарием предотвращения использования уязвимых мест [10]. Это дополнение к компилятору GCC (GNU Compiler Collection; gcc.gnu.org), который генерирует программы, устойчивые к такой разновидности переполнения буфера, как «разрушение стека» [11].

Рис. 1. StackGuard защищает от атак, разрушающих стек

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

StackGuard широко применяется с лета 1998 года. Разработчики используют его для создания полных версий Immunix Linux на основе Red Hat 5.2, 6.2 и 7.0. Однако StackGuard 2 (текущая версия) базируется на GCC 2.91.66, а в период подготовки статьи был практически завершен перенос на GCC 3.2. Распространяется на условиях лицензии GPL.

Статические анализаторы

Статические анализаторы проверяют исходные тексты и сообщают о подозрительных строках кода, которые могут оказаться уязвимыми. В отличие от компиляторов «строго типизированных» языков, таких как Java и ML, статические анализаторы могут посчитать подозрительными совершенно безопасные фрагменты кода. Однако излишняя подозрительность приводит к увеличению соотношения ложных/истинных тревог. Если статический анализатор слишком часто поднимает тревогу, разработчики начинают относиться к нему с недоверием и зачастую вообще отказываются от него. Так что избирательность для анализатора исходных текстов абсолютно необходима. С другой стороны, анализатор должен обладать достаточно высокой восприимчивостью. Если анализатор пропускает некоторые случаи патологий, на поиск которых он рассчитан (нераспознавание ошибки), он внушает разработчикам ложное чувство уверенности.

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

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

BOON - инструментарий, который на основе глубокого семантического анализа автоматизирует процесс сканирования исходных текстов на Си в поисках уязвимых мест, способных приводить к переполнению буфера. Он выявляет возможные дефекты, предполагая, что некоторые значения являются частью неявного типа с конкретным размером буфера [3]. CQual - инструментарий анализа на базе типов для поиска ошибок в программах на Си.
Он расширяет систему типов языка Си, добавляя к ним определенные пользователем идентификаторы типов. Программисты снабжают свои программы аннотациями, а CQual выполняет вывод идентификаторов, проверяя, корректны ли эти аннотации. Недавно в CQual были внесены изменения, благодаря которым этот инструментарий теперь может проверять согласованность и полноту использования "хуков" Linux Security Module в ядре Linux [4]. Также было расширено понятие аннотации типа с тем, чтобы инструментарий мог выявлять уязвимые места, возникающие из-за использования строки формата оператора printf [5]. MOPS (MOdel checking Programs for Security) - инструментарий для поиска ошибок в защите в программах на Си и проверки отсутствия таких ошибок. MOPS использует модель аудита программного обеспечения, которая призвана помочь выяснить, соответствует ли программа набору правил, определенному для создания безопасных программ. Исследования продолжаются [6].

RATS. Инструментарий Rough Auditing Tool for Security — утилита для проверки безопасности программ, написанных на языках Си, C++, Python, Perl и PHP. Сканирует исходный текст в поисках потенциально опасных вызовов функций. Цель разработки заключается не в том, чтобы непременно найти ошибки, — необходимо сделать обоснованные выводы, опираясь на которые специалист сможет вручную выполнять проверку кода. RATS использует сочетание проверок надежности защиты, от семантических проверок в ITS4 [7] до глубокого семантического анализа в поисках дефектов, способных привести к переполнению буфера, полученных из MOPS [3]. RATS распространяется в соответствии с лицензией GNU Public License (GPL).

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



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

PScan. В июне 2000 года исследователи обнаружили новый и достаточно обширный класс уязвимых мест, получивший название «ошибки формата» [8]. Проблема связана с описателем формата %n оператора форматного вывода строк printf, который указывает число байт, выводимых для соответствующего аргумента printf, при условии, что данный аргумент существует и имеет тип int *. Этот описатель может быть использован для нарушения защиты, если программа позволяет передавать «неотфильтрованные» данные непосредственно как первый аргумент printf.

Это действительно «дыра»: раньше повсеместно считалось, что строки формата совершенно безопасны. Впоследствии же в широко применяемых инструментальных средствах обнаружились десятки дефектов, связанных с форматами [9].

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

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

Управление поведением

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

Факторы риска

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

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

В качестве причин, которые привели к нарушению безопасности и значительным (более двух часов) простоям информационных систем, допускаемые сотрудниками ошибки упоминаются для СНГ в 9%случаев, а для дальнего зарубежья – в 4%, а операционные ошибки персонала (как, например, некорректное использование программного обеспечения) – в 14% и 15% соответственно.

Риски безопасности со стороны работающего персонала заметно увеличились из-за частого обновления сотрудников и совмещения функций и ролей работающих специалистов. С целью повышения квалификации персонала периодически проводятся тренинги и учебные семинары. Согласно тому же опросу, менее 40%респондентов из СНГ сообщили о регулярном проведении тренингов. Еще меньше (20%)постоянно проводят семинары и инструктажи по информационной безопасности.

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

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

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

И еще одна проблема заслуживает пристального внимания. На протяжении десяти лет наблюдается тенденция расхождения, причем увеличивающегося расхождения, объемов финансирования безопасности и сферы IT в целом. В той же Великобритании, по данным Конфедерации британской промышленности (CBI), только 27% организаций инвестируют в безопасность предприятия более 1%своего IT бюджета, а 30% проводят оценку возврата инвестиций (ROI)для данной сферы.

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

Инвентаризация информации

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

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

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

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

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

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

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

Определение угроз

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

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

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

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

Отправной момент

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

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

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

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

P_moment

Поиск слабых мест

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

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

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

Политический момент

Лидия Сирота,

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

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

Политика и практика

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

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

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

"Полномочия"

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

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

Сферы ответственности

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

Интересно, что практика аутсорсинга процедур по обеспечению информационной безопасности предприятия не является чем-то из ряда вон выходящим. По данным обзора Information Security Breaches Survey 2004, к подобной практике прибегают свыше 40%британских организаций.

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

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

Технологии - это не все

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

Министерство торговли и промышленности Великобритании совместно с Pricewaterhouse-Coopers периодически готовит и публикует обзоры, касающиеся состояния информационной безопасности в стране. По данным недавнего обзора International Security Breaches Survey 2004, за последние два года более 74%британских организаций пострадали от нарушения безопасности. В обзоре 2002 года их число составляло немногим более 60%, а рост объясняется увеличением числа угроз.

Вместе с тем только 30%от общей численности рассмотренных британских организаций имеют надлежащим образом разработанную и действенную политику информационной безопасности. В обзоре 2002 года таких организаций насчитывалось около 27%.

У 56%организаций отсутствуют задокументированные процедуры защиты данных. По сравнению с ситуацией двухгодичной давности этот показатель вырос всего на 4%. И это все несмотря на то, что потери, которые наносит наиболее ощутимый инцидент, связанный с нарушением безопасности, в среднем по стране составляют не менее 7 тыс. фунтов стерлингов ($12, 6 тыс. )на организацию, включая компании с численностью до 49 человек. На преодоление последствий расходуется от двух до четырех человеко-дней. Данные анализа для крупных предприятий (свыше 250 сотрудников) свидетельствуют о том, что в случае наиболее ощутимого инцидента усредненный показатель минимального уровня потерь доходит уже до 65 тыс.
фунтов. Средние трудозатраты на преодоление последствий инцидентов в таких компаниях составляют от десяти до двадцати человеко-дней. Но и у 35%крупных компаний в Великобритании нет действенной политики безопасности, а у 20%как следует не задокументированы процедуры по защите данных.

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

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

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

Уровни контроля

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

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

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

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

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

Заключительный этап

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

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

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

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

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

---

---