Что такое политика безопасности в организации


Политика безопасности - это... Что такое Политика безопасности?

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

Политика безопасности зависит:

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

Методы оценки

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

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

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

Предполагаемые ущербы

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

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

Величина ущерба Описание
0 Раскрытие информации принесет ничтожный моральный и финансовый ущерб фирме
1 Ущерб от атаки есть, но он незначителен, основные финансовые операции и положение фирмы на рынке не затронуты
2 Финансовые операции не ведутся в течение некоторого времени, за это время фирма терпит убытки, но ее положение на рынке и количество клиентов изменяются минимально
3 Значительные потери на рынке и в прибыли. От фирмы уходит ощутимая часть клиентов
4 Потери очень значительны, фирма на период до года теряет положение на рынке. Для восстановления положения требуются крупные финансовые займы.
5 Фирма прекращает существование

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

Вероятность Средняя частота появления
0 Данный вид атаки отсутствует
1 реже, чем раз в год
2 около 1 раза в год
3 около 1 раза в месяц
4 около 1 раза в неделю
5 практически ежедневно

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

Риск предприятия

Следующим этапом составляется таблица рисков предприятия. Она имеет следующий вид :

Описание атаки Ущерб Вероятность Риск (=Ущерб*Вероятность)
Спам (переполнение почтового ящика) 1 4 4
Копирование жесткого диска из центрального офиса 3 1 3
2
Итого :  9

На этапе анализа таблицы рисков задаются некоторым максимально допустимым риском, например значением 7. Сначала проверяется каждая строка таблицы на не превышение риска этого значения. Если такое превышение имеет место, значит, данная строка – это одна из первоочередных целей разработки политики безопасности. Затем производится сравнение удвоенного значения (в нашем случае 7*2=14) с интегральным риском (ячейка «Итого»).

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

Источники

См. также

Внешние ссылки

Примеры политики безопасности

Политика безопасности организации

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

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

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

Основные составляющие политики безопасности ИТ:

  • определение целей политики безопасности;

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

  • краткое разъяснение (дайджест) политики безопасности;

  • соответствие законодательным актам и стандартам;

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

  • определение политики обеспечения непрерывности работы и восстановления АС;

  • определение политики конфиденциальности стандартных сервисов (электронная почта (ЭП), Интернет, VPN, мобильные пользователи);

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

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

  • обнаружение и блокирование вирусов и других вредоносных програм м;

  • определение порядка разработки и сопровождения АС;

  • обучение персонала по вопросам безопасности ИТ;

  • защита от недекларированных возможностей ПО;

  • ликвидация последствий нарушения политики безопасности и ответственность нарушителей;

  • ссылки на более детальные документы по безопасности ИТ (положения, инструкции);

  • аудит и обновление политики безопасности.

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

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

  • отсутствие в организационно-штатной структуре организации специального подразделения, непосредственно ответственного за решение вопросов обеспечения безопасности ИТ в организации, за разработку и внедрение в организации единой технологии управления безопасностью ИТ;

  • неполнота и противоречивость нормативно-правовой базы организации по вопросам обеспечения безопасности ИТ, слабая увязка существующих организационно-распорядительных документов с реальными потребностями и требованиями законодательства Российской Федерации;

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

Для оценки текущего состояния ИТ в организации (насколько имеющиеся ИТ-средства и процессы эффективны «сами по себе» (с точки зрения ИТ) и для реализации бизнес- процессов, насколько безопасна имеющаяся ИТ-инфраструктура, какова стоимость ИТ для организации в терминах общей стоимости владения (ТСО) и каков возврат инвестиций, вложенных в ИТ-инфраструктуру, для бизнеса (ROI)) и получения ответа на вопрос «что делать, если текущее положение дел не устраивает?» можно воспользоваться существующими различными методиками и моделями зрелости или оптимизации ИТ- инфраструктуры, предлагаемыми известными исследовательскими и консалтинговыми организациями в области ИТ. Среди таких методик можно назвать Infrastructure Maturity Model (Gartner Group), Architecture Maturity Model (MTI), Infrastructure Optimization Model (Microsoft) и ряд других. Набор сервисов в моделях зрелости часто называют уровнем зрелости. Например, в Infrastructure Maturity Model (Gartner Group) определены четыре уровня зрелости (в сфере обеспечения ИБ):

0-й уровень:

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

  • финансирование отсутствует;

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

1-й уровень:

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

  • финансирование ведётся в рамках общего ИТ - бюджета;

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

2-й уровень:

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

  • финансирование ведётся в рамках отдельного бюджета

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

3-й уровень:

  • информационная безопасность является частью корпоративной культуры, назначен старший администратор по вопросам обеспечения информационной безопасности (CISA);

  • финансирование ведётся в рамках отдельного бюджета

  • информационная безопасность реализуется средствами второго уровня плюс система управления информационной безопасностью, группа реагирования на инциденты нарушения информационной безопасности (CSIRT), соглашение об уровне сервиса (SLA).

1.4. Как разработать политики безопасности?

1.4. Как разработать политики безопасности?

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

1.4.1. Кому и что доверять

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

•  доверять всем и всегда – самая простая модель доверия, но, к сожалению, непрактичная;

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

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

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

1.4.2. Трудности внедрения политик безопасности

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

1.4.3. Кто заинтересован в политиках безопасности?

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

1.4.4. Состав группы по разработке политик безопасности

Буклет SAGE «А Guide to Developing Computing Policy Documents» рекомендует следующий состав рабочей группы по разработке политик безопасности:

• член совета директоров;

• представитель руководства компании (СЕО, финансовый директор, директор по развитию);

• СЮ (директор службы автоматизации);

• CISO (директор по информационной безопасности);

• аналитик службы безопасности;

• аналитик ИТ-службы;

• представитель юридического отдела;

• представитель от пользователей;

• технический писатель.

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

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

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

1.4.6. Основные требования к политике безопасности

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

1.4.7. Уровень средств безопасности

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

1.4.8. Примеры политик безопасности

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

• допустимого шифрования,

• допустимого использования,

• аудита безопасности,

• оценки рисков,

• классификации данных,

• управления паролями,

• использования ноутбуков,

• построения демилитаризованной зоны (DMZ),

• построения экстранет,

• безопасности рабочих станций и серверов,

• антивирусной защиты,

• безопасности маршрутизаторов и коммутаторов,

• безопасности беспроводного доступа,

• организации удаленного доступа,

• построения виртуальных частных сетей (VPN) и пр.,

• безопасности периметра.

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

Примерный текст из описания политики допустимого использования:

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

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

Политика организации удаленного доступа определяет допустимые способы удаленного соединения с корпоративной информационной системой. Представляет собой основной документ безопасности в крупных транснациональных компаниях с географически разветвленной сетью. Должна описывать все доступные способы удаленного доступа к внутренним информационным ресурсам компании: доступ по коммутируемым сетям (SLIP, РРР), доступ с использованием ISDN/Frame Relay, Telnet/SSH-доступ через Интернет, выделенную линию/VPN/DSL и пр.

Примерный текст из описания политики организации удаленного доступа:

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

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

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

а) политика допустимого шифрования,

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

в) политика безопасности беспроводного доступа,

г) политика допустимого использования.

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

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

Пример требований политики удаленного доступа:

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

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

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

Маршрутизаторы для выделенных ISDN-линий, сконфигурированные для доступа к корпоративной сети, должны использовать для аутентификации, как минимум, СНАР».

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

Примерный текст из политики безопасности периметра:

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

Политика управления паролями определяет правила и порядок создания и изменения паролей сотрудников компании.

Примерный текст из описания политики управления паролями:

«Все пароли системного уровня (например, root, enable, administrator в системе Windows, пароли администраторов приложений и т. д.) должны изменяться по крайней мере раз в квартал. Все пароли системного уровня должны быть частью глобальной базы данных управления паролями отдела защиты информации. Все пароли пользовательского уровня (например, доступа к электронной почте, к сети, к настольному компьютеру и т. д.) должны изменяться по крайней мере раз в шесть месяцев. Рекомендованный интервал изменения – раз в четыре месяца. Учетные записи сотрудников, которым предоставляется доступ к административным учетным записям на системах с помощью членства в группах или программ sudo, должны иметь пароль, отличный от всех других паролей данного сотрудника».

Это только несколько примеров политик, которые могут быть использованы вашей компанией. С ними и другими политиками безопасности можно ознакомиться на Web-сайте американского института аудиторов и администраторов безопасности SANS (http://www.sans.org/newlook/resources/policies/policies.htm).

1.4.9. Процедуры безопасности

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

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

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

• в случае возможного простоя из-за изменения проблема будет быстро определена;

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

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

Следующая глава

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

Лекция № 9-10

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

Цель:познакомиться с особенностями организации политики безопасности.

Время: 4 часа.

План:

Введение. (10 мин.)

1. Целостность данных. (45 мин.)

2. Политика безопасности. (45 мин.)

3. Язык описания политики безопасности. (50 мин.)

Выводы. (10 мин.)

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

Литература:

1. Девянин П.Н. Модели безопасности компьютерных систем: Учеб. пособие / П. Н. Девянин. – М.: «Академия», 2005. – 114 с.

2. Мельников В.П. Информационная безопасность и защита информации / В.П. Мельников. – М.: «Академия», 2008. – 336 с.

3. Петров В.А. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах: Учебное пособие / В.А. Петров, А.С. Пискарев, А.В. Шеин. – М.: МИФИ, 2006.

4. Северин В.А. Комплексная защита информации на предприятии. Учебник для вузов / В.А. Северин. – М: « Городец», 2008 с.

Целостность данных

Под целостностью подразумевается отсутствие не надлежащих изменений. Одной из наиболее известных моделей целостности данных является модель Дэвида Кларка и Дэвида Уилсона. Смысл понятия не надлежащие изменения раскрывается следующим образом в модели Кларка-Уилсона:

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

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

1. корректность транзакций;

2. минимизация привилегий;

3. аутентификация пользователей;

4. разграничение функциональных обязанностей;

5. аудит произошедших событий;

6. объективный контроль;

7. управление передачей привилегий;

8. обеспечение непрерывной работоспособности;

9. простота использования защитных механизмов.

Корректность транзакций

Понятие корректности транзакций определяется в соответствии с моделью Кларка-Уилсона:

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

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

Минимизация привелегий

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

Разграничение функциональных обязанностей

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

Объективный контроль

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

Управление передачей привелегий

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

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

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

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

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

Необходимость и важность политики

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

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

· место каждого служащего в системе безопасности.

Какой должна быть безопасность

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

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

Определение различных политик

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

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

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

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

Виды политик

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

Классифицирование

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

Первый уровень – общая информация.

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

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

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

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

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

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

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

Аудит политики безопасности – определяет типы событий, отслеживаемых во всех системах:

· попытки входа в систему (успешные или неудачные);

· выход из системы;

· ошибки доступа к файлам или системным объектам;

· попытки удаленного доступа (успешные или неудачные);

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

· системные события (выключение и перезагрузка).

Каждое событие должно включать следующую информацию:

· ID пользователя (если имеется);

· дата и время;

· ID процесса (если имеется);

· выполненное действие;

· успешное или неудачное завершение события.

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

Сетевые соединения

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

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

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

Политика безопасности должна:

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

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

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

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

Отказ от защиты

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

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

· система с отказом от защиты;

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

· ответвления организации (обуславливают повышенную степень риска);

· шаги, предпринимаемые для снижения или контроля степени опасности;

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

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

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

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

Начальное состояние системы

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

· операционную систему и ее версию;

· уровень обновления;

· работающие приложения и их версии;

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

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

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

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

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

План DRP – сложный документ, который написать с первого раза довольно сложно. И даже после того, как он будет готов, необходима его тестировка.

Создание политики

Основные моменты при создании политики организации:

1. Определение найболее важных политик.

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

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

4. Определение схем политик.

5. Разработка.

Развертывание политики

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

1. Понимание политики.

2. Обучение. Сотрудники, на которых распространяется новая политика, должны пройти обучение согласно доли своей ответственности.

Объекто-субъектная модель

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

Контроль операций

Монитором взаимодействий контролирует все операции, и, соответственно, операции либо разрешаются, либо запрещаются.

Все операции контролируются и либо запрещаются, либо разрешаются в соответствии с правилами политики безопасности.

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

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

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

Классические модели

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

· дискреционные (произвольные);

· мандатные (нормативные).

Выразительная сила

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

Спецификации языка

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

· закрытые политики безопасности (все разрешенные виды доступа должны быть специфицированы);

· открытые политики безопасности (все запрещенные виды доступа должны быть специфицированы);

· гибридные политики безопасности;

· гибридные политики безопасности с разрешенными противоречиями.

Корректность спецификаций

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

Ацикличность

Eсли член ( ), то не может быть членом ( ). Уровни , и ничего не знают друг о друге.

Роль

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

Авторизация

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

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

Авторизацию

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

Политику контроля доступа

Предикат представляет или запрещает доступ для каждого субъекта к каждому объекту

Доступ

Предикат представляет доступы, выполненные субъектом

Концепция активной роли

Группировка объектов

Примеры

Лекция № 9-10

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

Цель:познакомиться с особенностями организации политики безопасности.

Время: 4 часа.

План:

Введение. (10 мин.)

1. Целостность данных. (45 мин.)

2. Политика безопасности. (45 мин.)

3. Язык описания политики безопасности. (50 мин.)

Выводы. (10 мин.)

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

Литература:

1. Девянин П.Н. Модели безопасности компьютерных систем: Учеб. пособие / П. Н. Девянин. – М.: «Академия», 2005. – 114 с.

2. Мельников В.П. Информационная безопасность и защита информации / В.П. Мельников. – М.: «Академия», 2008. – 336 с.

3. Петров В.А. Информационная безопасность. Защита информации от несанкционированного доступа в автоматизированных системах: Учебное пособие / В.А. Петров, А.С. Пискарев, А.В. Шеин. – М.: МИФИ, 2006.

4. Северин В.А. Комплексная защита информации на предприятии. Учебник для вузов / В.А. Северин. – М: « Городец», 2008 с.

Целостность данных

Под целостностью подразумевается отсутствие не надлежащих изменений. Одной из наиболее известных моделей целостности данных является модель Дэвида Кларка и Дэвида Уилсона. Смысл понятия не надлежащие изменения раскрывается следующим образом в модели Кларка-Уилсона:

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

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

1. корректность транзакций;

2. минимизация привилегий;

3. аутентификация пользователей;

4. разграничение функциональных обязанностей;

5. аудит произошедших событий;

6. объективный контроль;

7. управление передачей привилегий;

8. обеспечение непрерывной работоспособности;

9. простота использования защитных механизмов.

Корректность транзакций

Понятие корректности транзакций определяется в соответствии с моделью Кларка-Уилсона:

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

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

Минимизация привелегий

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


Смотрите также