Информационная безопасность. Угрозы информационной безопасности

МОСКОВСКИЙ АВИАЦИОННЫЙ ИНСТИТУТ (НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ) Факультет радиоэлектроники летательных аппаратов Кафедра № 402 Материал к лекционным занятиям по дисциплине «АБОИТ» Москва, 2017 г. ЛЕКЦИЯ 1. ИНФОРМАЦИОННАЯ БЕЗОПАСНОСТЬ. УГРОЗЫ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ 1.1. Основные понятия информационной безопасности Прежде чем говорить об обеспечении безопасности персональных данных, необходимо определить, что же такое информационная безопасность. Термин "информационная безопасность" может иметь различный смысл и трактовку в зависимости от контекста. В данном курсе под информационной безопасностью мы будем понимать защищенность информации и поддерживающей инфраструктуры от случайных или преднамеренных воздействий естественного или искусственного характера, которые могут нанести неприемлемый ущерб субъектам информационных отношений, в том числе владельцам и пользователям информации и поддерживающей инфраструктуры ГОСТ "Защита информации. Основные термины и определения" вводит понятие информационной безопасности как состояние защищенности информации, при котором обеспечены ее конфиденциальность, доступность и целостность. • Конфиденциальность – состояние информации, при котором доступ к ней осуществляют только субъекты, имеющие на него право. • Целостность – состояние информации, при котором отсутствует любое ее изменение либо изменение осуществляется только преднамеренно субъектами, имеющими на него право; • Доступность – состояние информации, при котором субъекты, имеющие право доступа, могут реализовывать его беспрепятственно. Угрозы информационной безопасности – совокупность условий и факторов, создающих потенциальную или реально существующую опасность нарушения безопасности информации.  Атакой называется попытка реализации угрозы, а тот, кто предпринимает такую попытку, - злоумышленником. Потенциальные злоумышленники называются источниками угрозы. Угроза является следствием наличия уязвимых мест или уязвимостей в информационной системе. Уязвимости могут возникать по разным причинам, например, в результате непреднамеренных ошибок программистов при написании программ. Угрозы можно классифицировать по нескольким критериям: • по свойствам информации (доступность, целостность, конфиденциальность), против которых угрозы направлены в первую очередь; • по компонентам информационных систем, на которые угрозы нацелены (данные, программы, аппаратура, поддерживающая инфраструктура); • по способу осуществления (случайные/преднамеренные, действия природного/техногенного характера); • по расположению источника угроз (внутри/вне рассматриваемой ИС). Обеспечение информационной безопасности является сложной задачей, для решения которой требуется комплексный подход. Выделяют следующие уровни защиты информации: 1. законодательный – законы, нормативные акты и прочие документы РФ и международного сообщества; 2. административный – комплекс мер, предпринимаемых локально руководством организации; 3. процедурный уровень – меры безопасности, реализуемые людьми; 4. программно-технический уровень – непосредственно средства защиты информации. Законодательный уровень является основой для построения системы защиты информации, так как дает базовые понятия предметной области и определяет меру наказания для потенциальных злоумышленников. Этот уровень играет координирующую и направляющую роли и помогает поддерживать в обществе негативное (и карательное) отношение к людям, нарушающим информационную безопасность. 1.2. ФЗ "Об информации, информационных технологиях и о защите информации" В российском законодательстве базовым законом в области защиты информации является ФЗ "Об информации, информационных технологиях и о защите информации" от 27 июля 2006 года номер 149-ФЗ. Поэтому основные понятия и решения, закрепленные в законе, требуют пристального рассмотрения. Закон регулирует отношения, возникающие при: • осуществлении права на поиск, получение, передачу, производство и распространение информации; • применении информационных технологий; • обеспечении защиты информации. Закон дает основные определения в области защиты информации. Приведем некоторые из них: • информация - сведения (сообщения, данные) независимо от формы их представления; • информационные технологии - процессы, методы поиска, сбора, хранения, обработки, предоставления, распространения информации и способы осуществления таких процессов и методов; • информационная система - совокупность содержащейся в базах данных информации и обеспечивающих ее обработку информационных технологий и технических средств; • обладатель информации - лицо, самостоятельно создавшее информацию либо получившее на основании закона или договора право разрешать или ограничивать доступ к информации, определяемой по каким-либо признакам; • оператор информационной системы - гражданин или юридическое лицо, осуществляющие деятельность по эксплуатации информационной системы, в том числе по обработке информации, содержащейся в ее базах данных. • конфиденциальность информации - обязательное для выполнения лицом, получившим доступ к определенной информации, требование не передавать такую информацию третьим лицам без согласия ее обладателя . В статье 4 Закона сформулированы принципы правового регулирования отношений в сфере информации, информационных технологий и защиты информации: 1. свобода поиска, получения, передачи, производства и распространения информации любым законным способом; 2. установление ограничений доступа к информации только федеральными законами; 3. открытость информации о деятельности государственных органов и органов местного самоуправления и свободный доступ к такой информации, кроме случаев, установленных федеральными законами; 4. равноправие языков народов Российской Федерации при создании информационных систем и их эксплуатации; 5. обеспечение безопасности Российской Федерации при создании информационных систем, их эксплуатации и защите содержащейся в них информации; 6. достоверность информации и своевременность ее предоставления; 7. неприкосновенность частной жизни, недопустимость сбора, хранения, использования и распространения информации о частной жизни лица без его согласия; 8. недопустимость установления нормативными правовыми актами каких-либо преимуществ применения одних информационных технологий перед другими, если только обязательность применения определенных информационных технологий для создания и эксплуатации государственных информационных систем не установлена федеральными законами. Вся информация делится на общедоступную и ограниченного доступа. К общедоступной информации относятся общеизвестные сведения и иная информация, доступ к которой не ограничен. В законе, определяется информация, к которой нельзя ограничить доступ, например, информация об окружающей среде или деятельности государственных органов. Оговаривается также, что ограничение доступа к информации устанавливается федеральными законами в целях защиты основ конституционного строя, нравственности, здоровья, прав и законных интересов других лиц, обеспечения обороны страны и безопасности государства. Обязательным является соблюдение конфиденциальности информации, доступ к которой ограничен федеральными законами. Запрещается требовать от гражданина (физического лица) предоставления информации о его частной жизни, в том числе информации, составляющей личную или семейную тайну, и получать такую информацию помимо воли гражданина (физического лица), если иное не предусмотрено федеральными законами. Закон выделяет 4 категории информации в зависимости от порядка ее предоставления или распространения: 1. информацию, свободно распространяемую; 2. информацию, предоставляемую по соглашению лиц, участвующих в соответствующих отношениях; 3. информацию, которая в соответствии с федеральными законами подлежит предоставлению или распространению; 4. информацию, распространение которой в Российской Федерации ограничивается или запрещается. Закон устанавливает равнозначность электронного сообщения, подписанного электронной цифровой подписью или иным аналогом собственноручной подписи, и документа, подписанного собственноручно. Дается следующее определение защите информации - представляет собой принятие правовых, организационных и технических мер, направленных на: 1. обеспечение защиты информации от неправомерного доступа, уничтожения, модифицирования, блокирования, копирования, предоставления, распространения, а также от иных неправомерных действий в отношении такой информации; 2. соблюдение конфиденциальности информации ограниченного доступа; 3. реализацию права на доступ к информации. Обладатель информации, оператор информационной системы в случаях, установленных законодательством Российской Федерации, обязаны обеспечить: 1. предотвращение несанкционированного доступа к информации и (или) передачи ее лицам, не имеющим права на доступ к информации; 2. своевременное обнаружение фактов несанкционированного доступа к информации; 3. предупреждение возможности неблагоприятных последствий нарушения порядка доступа к информации; 4. недопущение воздействия на технические средства обработки информации, в результате которого нарушается их функционирование; 5. возможность незамедлительного восстановления информации, модифицированной или уничтоженной вследствие несанкционированного доступа к ней; 6. постоянный контроль за обеспечением уровня защищенности информации. Таким образом, ФЗ "Об информации, информационных технологиях и о защите информации" создает правовую основу информационного обмена в РФ и определяет права и обязанности его субъектов. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Дайте определение понятию - информационная безопасность 2. Какие 4 категории информации закон « О защите информации» выделяет 3. Перечислите основные термины и определения которые вводит понятие информационной безопасности  4. Что такое ограничение доступа 5. Перечислите основные угрозы безопасности информации ЛЕКЦИЯ 2. ЗАКОНОДАТЕЛЬНЫЙ УРОВЕНЬ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ. СТАНДАРТЫ И СПЕЦИФИКАЦИИ В ОБЛАСТИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ Мы приступаем к обзору стандартов и спецификаций двух разных видов: • оценочных стандартов, направленных на классификацию информационных систем и средств защиты по требованиям безопасности; • технических спецификаций, регламентирующих различные аспекты реализации средств защиты. Важно отметить, что между этими видами нормативных документов нет глухой стены. Оценочные стандарты выделяют важнейшие, с точки зрения ИБ, аспекты ИС, играя роль архитектурных спецификаций. Другие технические спецификации определяют, как строить ИС предписанной архитектуры. Исторически первым оценочным стандартом, получившим широкое распространение и оказавшим огромное влияние на базу стандартизации ИБ во многих странах, стал стандарт Министерства обороны США "Критерии оценки доверенных компьютерных систем". Данный труд, называемый чаще всего по цвету обложки "Оранжевой книгой", был впервые опубликован в августе 1983 года. Уже одно его название требует комментария. Речь идет не о безопасных, а о доверенных системах, то есть системах, которым можно оказать определенную степень доверия. "Оранжевая книга" поясняет понятие безопасной системы, которая "управляет, с помощью соответствующих средств, доступом к информации так, что только должным образом авторизованные лица или процессы, действующие от их имени, получают право читать, записывать, создавать и удалять информацию". Очевидно, однако, что абсолютно безопасных систем не существует, это абстракция. Есть смысл оценивать лишь степень доверия, которое можно оказать той или иной системе. В "Оранжевой книге" доверенная система определяется как "система, использующая достаточные аппаратные и программные средства, чтобы обеспечить одновременную обработку информации разной степени секретности группой пользователей без нарушения прав доступа". Обратим внимание, что в рассматриваемых Критериях и безопасность, и доверие оцениваются исключительно с точки зрения управления доступом к данным, что является одним из средств обеспечения конфиденциальности и целостности (статической). Вопросы доступности "Оранжевая книга" не затрагивает. Степень доверия оценивается по двум основным критериям. 1. Политика безопасности - набор законов, правил и норм поведения, определяющих, как организация обрабатывает, защищает и распространяет информацию. В частности, правила определяют, в каких случаях пользователь может оперировать конкретными наборами данных. Чем выше степень доверия системе, тем строже и многообразнее должна быть политика безопасности. В зависимости от сформулированной политики можно выбирать конкретные механизмы обеспечения безопасности. Политика безопасности - это активный аспект защиты, включающий в себя анализ возможных угроз и выбор мер противодействия. 2. Уровень гарантированности - мера доверия, которая может быть оказана архитектуре и реализации ИС. Доверие безопасности может проистекать как из анализа результатов тестирования, так и из проверки (формальной или нет) общего замысла и реализации системы в целом и отдельных ее компонентов. Уровень гарантированности показывает, насколько корректны механизмы, отвечающие за реализацию политики безопасности. Это пассивный аспект защиты. Важным средством обеспечения безопасности является механизм подотчетности (протоколирования). Доверенная система должна фиксировать все события, касающиеся безопасности. Ведение протоколов должно дополняться аудитом, то есть анализом регистрационной информации. Концепция доверенной вычислительной базы является центральной при оценке степени доверия безопасности. Доверенная вычислительная база - это совокупность защитных механизмов ИС (включая аппаратное и программное обеспечение), отвечающих за проведение в жизнь политики безопасности. Качество вычислительной базы определяется исключительно ее реализацией и корректностью исходных данных, которые вводит системный администратор. Вообще говоря, компоненты вне вычислительной базы могут не быть доверенными, однако это не должно влиять на безопасность системы в целом. В результате, для оценки доверия безопасности ИС достаточно рассмотреть только ее вычислительную базу, которая, как можно надеяться, достаточно компактна. Основное назначение доверенной вычислительной базы - выполнять функции монитора обращений, то есть контролировать допустимость выполнения субъектами (активными сущностями ИС, действующими от имени пользователей) определенных операций над объектами (пассивными сущностями). Монитор проверяет каждое обращение пользователя к программам или данным на предмет согласованности с набором действий, допустимых для пользователя. Монитор обращений должен обладать тремя качествами: 1. Изолированность. Необходимо предупредить возможность отслеживания работы монитора. 2. Полнота. Монитор должен вызываться при каждом обращении, не должно быть способов обойти его. 3. Верифицируемость. Монитор должен быть компактным, чтобы его можно было проанализировать и протестировать, будучи уверенным в полноте тестирования. Реализация монитора обращений называется ядром безопасности. Ядро безопасности - это основа, на которой строятся все защитные механизмы. Помимо перечисленных выше свойств монитора обращений, ядро должно гарантировать собственную неизменность. Границу доверенной вычислительной базы называют периметром безопасности. Как уже указывалось, компоненты, лежащие вне периметра безопасности, вообще говоря, могут не быть доверенными. С развитием распределенных систем понятию "периметр безопасности" все чаще придают другой смысл, имея в виду границу владений определенной организации. То, что находится внутри владений, считается доверенным, а то, что вне, - нет. ​ Механизмы безопасности Согласно "Оранжевой книге", политика безопасности должна обязательно включать в себя следующие элементы: • произвольное управление доступом; • безопасность повторного использования объектов; • метки безопасности; • принудительное управление доступом. Произвольное управление доступом (называемое иногда дискреционным) - это метод разграничения доступа к объектам, основанный на учете личности субъекта или группы, в которую субъект входит. Произвольность управления состоит в том, что некоторое лицо (обычно владелец объекта) может по своему усмотрению предоставлять другим субъектам или отбирать у них права доступа к объекту. Безопасность повторного использования объектов - важное дополнение средств управления доступом, предохраняющее от случайного или преднамеренного извлечения конфиденциальной информации из "мусора". Безопасность повторного использования должна гарантироваться для областей оперативной памяти (в частности, для буферов с образами экрана, расшифрованными паролями и т.п.), для дисковых блоков и магнитных носителей в целом. Как мы указывали ранее, современный объектно-ориентированный подход резко сужает область действия данного элемента безопасности, затрудняет его реализацию. То же верно и для интеллектуальных устройств, способных буферизовать большие объемы данных. Для реализации принудительного управления доступом с субъектами и объектами ассоциируются метки безопасности. Метка субъекта описывает его благонадежность, метка объекта - степень конфиденциальности содержащейся в нем информации. Согласно "Оранжевой книге", метки безопасности состоят из двух частей - уровня секретности и списка категорий. Уровни секретности образуют упорядоченное множество, категории - неупорядоченное. Назначение последних - описать предметную область, к которой относятся данные. Принудительное (или мандатное) управление доступом основано на сопоставлении меток безопасности субъекта и объекта. Субъект может читать информацию из объекта, если уровень секретности субъекта не ниже, чем у объекта, а все категории, перечисленные в метке безопасности объекта, присутствуют в метке субъекта. В таком случае говорят, что метка субъекта доминирует над меткой объекта. Смысл сформулированного правила понятен - читать можно только то, что положено. Субъект может записывать информацию в объект, если метка безопасности объекта доминирует над меткой субъекта. В частности, "конфиденциальный" субъект может записывать данные в секретные файлы, но не может - в несекретные (разумеется, должны также выполняться ограничения на набор категорий). Описанный способ управления доступом называется принудительным, поскольку он не зависит от воли субъектов (даже системных администраторов). После того, как зафиксированы метки безопасности субъектов и объектов, оказываются зафиксированными и права доступа. Если понимать политику безопасности узко, то есть как правила разграничения доступа, то механизм подотчетности является дополнением подобной политики. Цель подотчетности - в каждый момент времени знать, кто работает в системе и что делает. Средства подотчетности делятся на три категории: • идентификация и аутентификация; • предоставление доверенного пути; • анализ регистрационной информации. Обычный способ идентификации - ввод имени пользователя при входе в систему. Стандартное средство проверки подлинности (аутентификации) пользователя - пароль. Доверенный путь связывает пользователя непосредственно с доверенной вычислительной базой, минуя другие, потенциально опасные компоненты ИС. Цель предоставления доверенного пути - дать пользователю возможность убедиться в подлинности обслуживающей его системы. Анализ регистрационной информации (аудит) имеет дело с действиями (событиями), так или иначе затрагивающими безопасность системы. Если фиксировать все события, объем регистрационной информации, скорее всего, будет расти слишком быстро, а ее эффективный анализ станет невозможным. "Оранжевая книга" предусматривает наличие средств выборочного протоколирования, как в отношении пользователей (внимательно следить только за подозрительными), так и в отношении событий. Переходя к пассивным аспектам защиты, укажем, что в "Оранжевой книге" рассматривается два вида гарантированности - операционная и технологическая. Операционная гарантированность относится к архитектурным и реализационным аспектам системы, в то время как технологическая - к методам построения и сопровождения. Операционная гарантированность включает в себя проверку следующих элементов: • архитектура системы; • целостность системы; • проверка тайных каналов передачи информации; • доверенное администрирование; • доверенное восстановление после сбоев. Операционная гарантированность - это способ убедиться в том, что архитектура системы и ее реализация действительно реализуют избранную политику безопасности. Технологическая гарантированность охватывает весь жизненный цикл ИС, то есть периоды проектирования, реализации, тестирования, продажи и сопровождения. Все перечисленные действия должны выполняться в соответствии с жесткими стандартами, чтобы исключить утечку информации и нелегальные "закладки". ​ Классы безопасности "Критерии ..." Министерства обороны США открыли путь к ранжированию информационных систем по степени доверия безопасности. В "Оранжевой книге" определяется четыре уровня доверия - D, C, B и A. Уровень D предназначен для систем, признанных неудовлетворительными. По мере перехода от уровня C к A к системам предъявляются все более жесткие требования. Уровни C и B подразделяются на классы (C1, C2, B1, B2, B3) с постепенным возрастанием степени доверия. Всего имеется шесть классов безопасности - C1, C2, B1, B2, B3, A1. Чтобы в результате процедуры сертификации систему можно было отнести к некоторому классу, ее политика безопасности и уровень гарантированности должны удовлетворять заданным требованиям, из которых мы упомянем лишь важнейшие. Класс C1: • доверенная вычислительная база должна управлять доступом именованных пользователей к именованным объектам; • пользователи должны идентифицировать себя, прежде чем выполнять какие-либо иные действия, контролируемые доверенной вычислительной базой. Для аутентификации должен использоваться какой-либо защитный механизм, например пароли. Аутентификационная информация должна быть защищена от несанкционированного доступа; • доверенная вычислительная база должна поддерживать область для собственного выполнения, защищенную от внешних воздействий (в частности, от изменения команд и/или данных) и от попыток слежения за ходом работы; • должны быть в наличии аппаратные и/или программные средства, позволяющие периодически проверять корректность функционирования аппаратных и микропрограммных компонентов доверенной вычислительной базы; • защитные механизмы должны быть протестированы на предмет соответствия их поведения системной документации. Тестирование должно подтвердить, что у неавторизованного пользователя нет очевидных способов обойти или разрушить средства защиты доверенной вычислительной базы; • должны быть описаны подходы к безопасности, используемый производителем, и применение этого подхода при реализации доверенной вычислительной базы. Класс C2 (в дополнение к C1): • права доступа должны гранулироваться с точностью до пользователя. Все объекты должны подвергаться контролю доступа; • при выделении хранимого объекта из пула ресурсов доверенной вычислительной базы необходимо ликвидировать все следы его использования; • каждый пользователь системы должен уникальным образом идентифицироваться. Каждое регистрируемое действие должно ассоциироваться с конкретным пользователем; • доверенная вычислительная база должна создавать, поддерживать и защищать журнал регистрационной информации, относящейся к доступу к объектам, контролируемым базой; • тестирование должно подтвердить отсутствие очевидных недостатков в механизмах изоляции ресурсов и защиты регистрационной информации. Класс B1 (в дополнение к C2): • доверенная вычислительная база должна управлять метками безопасности, ассоциируемыми с каждым субъектом и хранимым объектом; • доверенная вычислительная база должна обеспечить реализацию принудительного управления доступом всех субъектов ко всем хранимым объектам; • доверенная вычислительная база должна обеспечивать взаимную изоляцию процессов путем разделения их адресных пространств; • группа специалистов, полностью понимающих реализацию доверенной вычислительной базы, должна подвергнуть описание архитектуры, исходные и объектные коды тщательному анализу и тестированию; • должна существовать неформальная или формальная модель политики безопасности, поддерживаемой доверенной вычислительной базой. Класс B2 (в дополнение к B1): • снабжаться метками должны все ресурсы системы (например, ПЗУ), прямо или косвенно доступные субъектам; • к доверенной вычислительной базе должен поддерживаться доверенный коммуникационный путь для пользователя, выполняющего операции начальной идентификации и аутентификации; • должна быть предусмотрена возможность регистрации событий, связанных с организацией тайных каналов обмена с памятью; • доверенная вычислительная база должна быть внутренне структурирована на хорошо определенные, относительно независимые модули; • системный архитектор должен тщательно проанализировать возможности организации тайных каналов обмена с памятью и оценить максимальную пропускную способность каждого выявленного канала; • должна быть продемонстрирована относительная устойчивость доверенной вычислительной базы к попыткам проникновения; • модель политики безопасности должна быть формальной. Для доверенной вычислительной базы должны существовать описательные спецификации верхнего уровня, точно и полно определяющие ее интерфейс; • в процессе разработки и сопровождения доверенной вычислительной базы должна использоваться система конфигурационного управления, обеспечивающая контроль изменений в описательных спецификациях верхнего уровня, иных архитектурных данных, реализационной документации, исходных текстах, работающей версии объектного кода, тестовых данных и документации; • тесты должны подтверждать действенность мер по уменьшению пропускной способности тайных каналов передачи информации. Класс B3 (в дополнение к B2): • для произвольного управления доступом должны обязательно использоваться списки управления доступом с указанием разрешенных режимов; • должна быть предусмотрена возможность регистрации появления или накопления событий, несущих угрозу политике безопасности системы. Администратор безопасности должен немедленно извещаться о попытках нарушения политики безопасности, а система, в случае продолжения попыток, должна пресекать их наименее болезненным способом; • доверенная вычислительная база должна быть спроектирована и структурирована таким образом, чтобы использовать полный и концептуально простой защитный механизм с точно определенной семантикой; • процедура анализа должна быть выполнена для временных тайных каналов; • должна быть специфицирована роль администратора безопасности. Получить права администратора безопасности можно только после выполнения явных, протоколируемых действий; • должны существовать процедуры и/или механизмы, позволяющие произвести восстановление после сбоя или иного нарушения работы без ослабления защиты; • должна быть продемонстрирована устойчивость доверенной вычислительной базы к попыткам проникновения. Класс A1 (в дополнение к B3): • тестирование должно продемонстрировать, что реализация доверенной вычислительной базы соответствует формальным спецификациям верхнего уровня; • помимо описательных, должны быть представлены формальные спецификации верхнего уровня. Необходимо использовать современные методы формальной спецификации и верификации систем; • механизм конфигурационного управления должен распространяться на весь жизненный цикл и все компоненты системы, имеющие отношение к обеспечению безопасности; • должно быть описано соответствие между формальными спецификациями верхнего уровня и исходными текстами. Такова классификация, введенная в "Оранжевой книге". Коротко ее можно сформулировать так: • уровень C - произвольное управление доступом; • уровень B - принудительное управление доступом; • уровень A - верифицируемая безопасность. Конечно, в адрес "Критериев ..." можно высказать целый ряд серьезных замечаний (таких, например, как полное игнорирование проблем, возникающих в распределенных системах). Тем не менее, следует подчеркнуть, что публикация "Оранжевой книги" без всякого преувеличения стала эпохальным событием в области информационной безопасности. Появился общепризнанный понятийный базис, без которого даже обсуждение проблем ИБ было бы затруднительным. Отметим, что огромный идейный потенциал "Оранжевой книги" пока во многом остается невостребованным. Прежде всего это касается концепции технологической гарантированности, охватывающей весь жизненный цикл системы - от выработки спецификаций до фазы эксплуатации. При современной технологии программирования результирующая система не содержит информации, присутствующей в исходных спецификациях, теряется информация о семантике программ. Важность данного обстоятельства мы планируем продемонстрировать далее, в лекции об управлении доступом. ​ Информационная безопасность распределенных систем. Рекомендации X.800 ​ Сетевые сервисы безопасности Следуя скорее исторической, чем предметной логике, мы переходим к рассмотрению технической спецификации X.800, появившейся немногим позднее "Оранжевой книги", но весьма полно и глубоко трактующей вопросы информационной безопасности распределенных систем. Рекомендации X.800 - документ довольно обширный. Мы остановимся на специфических сетевых функциях (сервисах) безопасности, а также на необходимых для их реализации защитных механизмах. Выделяют следующие сервисы безопасности и исполняемые ими роли: Аутентификация. Данный сервис обеспечивает проверку подлинности партнеров по общению и проверку подлинности источника данных. Аутентификация партнеров по общению используется при установлении соединения и, быть может, периодически во время сеанса. Она служит для предотвращения таких угроз, как маскарад и повтор предыдущего сеанса связи. Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней (взаимной). Управление доступом. Обеспечивает защиту от несанкционированного использования ресурсов, доступных по сети. Конфиденциальность данных. Обеспечивает защиту от несанкционированного получения информации. Отдельно упомянем конфиденциальность трафика (это защита информации, которую можно получить, анализируя сетевые потоки данных). Целостность данных подразделяется на подвиды в зависимости от того, какой тип общения используют партнеры - с установлением соединения или без него, защищаются ли все данные или только отдельные поля, обеспечивается ли восстановление в случае нарушения целостности. Неотказуемость (невозможность отказаться от совершенных действий) обеспечивает два вида услуг: неотказуемость с подтверждением подлинности источника данных и неотказуемость с подтверждением доставки. Побочным продуктом неотказуемости является аутентификация источника данных. В следующей таблице указаны уровни эталонной семиуровневой модели OSI, на которых могут быть реализованы функции безопасности. Отметим, что прикладные процессы, в принципе, могут взять на себя поддержку всех защитных сервисов. Таблица 2.1. Распределение функций безопасности по уровням эталонной семиуровневой модели OSI Функции безопасности Уровень 1 2 3 4 5 6 7 Аутентификация - - + + - - + Управление доступом - - + + - - + Конфиденциальность соединения + + + + - + + Конфиденциальность вне соединения - + + + - + + Избирательная конфиденциальность - - - - - + + Конфиденциальность трафика + - + - - - + Целостность с восстановлением - - - + - - + Целостность без восстановления - - + + - - + Избирательная целостность - - - - - - + Целостность вне соединения - - + + - - + Неотказуемость - - - - - - + "+" данный уровень может предоставить функцию безопасности; "-" данный уровень не подходит для предоставления функции безопасности. ​ Сетевые механизмы безопасности Для реализации сервисов (функций) безопасности могут использоваться следующие механизмы и их комбинации: • шифрование; • электронная цифровая подпись; • механизмы управления доступом. Могут располагаться на любой из участвующих в общении сторон или в промежуточной точке; • механизмы контроля целостности данных. В рекомендациях X.800 различаются два аспекта целостности: целостность отдельного сообщения или поля информации и целостность потока сообщений или полей информации. Для проверки целостности потока сообщений (то есть для защиты от кражи, переупорядочивания, дублирования и вставки сообщений) используются порядковые номера, временные штампы, криптографическое связывание или иные аналогичные приемы; • механизмы аутентификации. Согласно рекомендациям X.800, аутентификация может достигаться за счет использования паролей, личных карточек или иных устройств аналогичного назначения, криптографических методов, устройств измерения и анализа биометрических характеристик; • механизмы дополнения трафика; • механизмы управления маршрутизацией. Маршруты могут выбираться статически или динамически. Оконечная система, зафиксировав неоднократные атаки на определенном маршруте, может отказаться от его использования. На выбор маршрута способна повлиять метка безопасности, ассоциированная с передаваемыми данными; • механизмы нотаризации. Служат для заверения таких коммуникационных характеристик, как целостность, время, личности отправителя и получателей. Заверение обеспечивается надежной третьей стороной, обладающей достаточной информацией. Обычно нотаризация опирается на механизм электронной подписи. В следующей таблице сведены сервисы (функции) и механизмы безопасности. Таблица показывает, какие механизмы (по отдельности или в комбинации с другими) могут использоваться для реализации той или иной функции. Таблица 2.2. Взаимосвязь функций и механизмов безопасности Функции Механизмы Шиф рова ние Элек трон ная под пись Управ ление досту пом Целост ность Аутен тифика ция Допол нение трафика Управ ление марш рутиза цией Нота риза ция Аутентификация партнеров + + - - + - - - Аутентификация источника + + - - - - - - Управление доступом - - + - - - - - Конфиденциальность + - + - - - + - Избирательная конфиденциальность + - - - - - - - Конфиденциальность трафика + - - - - + + - Целостность соединения + - - + - - - - Целостность вне соединения + + - + - - - - Неотказуемость - + - + - - - + "+" механизм пригоден для реализации данной функции безопасности; "-" механизм не предназначен для реализации данной функции безопасности. ​ Администрирование средств безопасности Администрирование средств безопасности включает в себя распространение информации, необходимой для работы сервисов и механизмов безопасности, а также сбор и анализ информации об их функционировании. Примерами могут служить распространение криптографических ключей, установка значений параметров защиты, ведение регистрационного журнала и т.п. Концептуальной основой администрирования является информационная база управления безопасностью. Эта база может не существовать как единое (распределенное) хранилище, но каждая из оконечных систем должна располагать информацией, необходимой для реализации избранной политики безопасности. Согласно рекомендациям X.800, усилия администратора средств безопасности должны распределяться по трем направлениям: • администрирование информационной системы в целом; • администрирование сервисов безопасности; • администрирование механизмов безопасности. Среди действий, относящихся к ИС в целом, отметим обеспечение актуальности политики безопасности, взаимодействие с другими административными службами, реагирование на происходящие события, аудит и безопасное восстановление. Администрирование сервисов безопасности включает в себя определение защищаемых объектов, выработку правил подбора механизмов безопасности (при наличии альтернатив), комбинирование механизмов для реализации сервисов, взаимодействие с другими администраторами для обеспечения согласованной работы. Обязанности администратора механизмов безопасности определяются перечнем задействованных механизмов. Типичный список таков: • управление ключами (генерация и распределение); • управление шифрованием (установка и синхронизация криптографических параметров). К управлению шифрованием можно отнести и администрирование механизмов электронной подписи. Управление целостностью, если оно обеспечивается криптографическими средствами, также тяготеет к данному направлению; • администрирование управления доступом (распределение информации, необходимой для управления - паролей, списков доступа и т.п.); • управление аутентификацией (распределение информации, необходимой для аутентификации - паролей, ключей и т.п.); • управление дополнением трафика (выработка и поддержание правил, задающих характеристики дополняющих сообщений - частоту отправки, размер и т.п.); • управление маршрутизацией (выделение доверенных путей); • управление нотаризацией (распространение информации о нотариальных службах, администрирование этих служб). Мы видим, что администрирование средств безопасности в распределенной ИС имеет много особенностей по сравнению с централизованными системами. ​ Стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий" ​ Основные понятия Мы возвращаемся к теме оценочных стандартов, приступая к рассмотрению самого полного и современного среди них - "Критериев оценки безопасности информационных технологий" (издан 1 декабря 1999 года). Этот международный стандарт стал итогом почти десятилетней работы специалистов нескольких стран, он вобрал в себя опыт существовавших к тому времени документов национального и межнационального масштаба. По историческим причинам данный стандарт часто называют "Общими критериями" (или даже ОК). Мы также будем использовать это сокращение. "Общие критерии" на самом деле являются метастандартом, определяющим инструменты оценки безопасности ИС и порядок их использования. В отличие от "Оранжевой книги", ОК не содержат предопределенных "классов безопасности". Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы. С программистской точки зрения ОК можно считать набором библиотек, помогающих писать содержательные "программы" - задания по безопасности, типовые профили защиты и т.п. Программисты знают, насколько хорошая библиотека упрощает разработку программ, повышает их качество. Без библиотек, "с нуля", программы не пишут уже очень давно; оценка безопасности тоже вышла на сопоставимый уровень сложности, и "Общие критерии" предоставили соответствующий инструментарий. Важно отметить, что требования могут быть параметризованы, как и полагается библиотечным функциям. Как и "Оранжевая книга", ОК содержат два основных вида требований безопасности: • функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам; • требования доверия, соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации. Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы: • определение назначения, условий применения, целей и требований безопасности; • проектирование и разработка; • испытания, оценка и сертификация; • внедрение и эксплуатация. В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами: • источник угрозы; • метод воздействия; • уязвимые места, которые могут быть использованы; • ресурсы (активы), которые могут пострадать. Уязвимые места могут возникать из-за недостатка в: • требованиях безопасности; • проектировании; • эксплуатации. Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс-семейство-компонент-элемент. Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Как и между библиотечными функциями, между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Вообще говоря, не все комбинации компонентов имеют смысл, и понятие зависимости в какой-то степени компенсирует недостаточную выразительность библиотечной организации, хотя и не заменяет объединение функций в содержательные объектные интерфейсы. Как указывалось выше, с помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. Выше мы отмечали, что в ОК нет готовых классов защиты. Сформировать классификацию в терминах "Общих критериев" - значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно, на наш взгляд, сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. Функциональный пакет - это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. "Общие критерии" не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. ​ Функциональные требования Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности. Всего в "Общих критериях" представлено 11 функциональных классов, 66 семейств, 135 компонентов. Это, конечно, значительно больше, чем число аналогичных сущностей в "Оранжевой книге". Перечислим классы функциональных требований ОК: • идентификация и аутентификация; • защита данных пользователя; • защита функций безопасности (требования относятся к целостности и контролю данных сервисов безопасности и реализующих их механизмов); • управление безопасностью (требования этого класса относятся к управлению атрибутами и параметрами безопасности); • аудит безопасности (выявление, регистрация, хранение, анализ данных, затрагивающих безопасность объекта оценки, реагирование на возможное нарушение безопасности); • доступ к объекту оценки; • приватность (защита пользователя от раскрытия и несанкционированного использования его идентификационных данных); • использование ресурсов (требования к доступности информации); • криптографическая поддержка (управление ключами); • связь (аутентификация сторон, участвующих в обмене данными); • доверенный маршрут/канал (для связи с сервисами безопасности). Опишем подробнее два класса, демонстрирующие особенности современного подхода к ИБ. Класс "Приватность" содержит 4 семейства функциональных требований. Анонимность. Позволяет выполнять действия без раскрытия идентификатора пользователя другим пользователям, субъектам и/или объектам. Анонимность может быть полной или выборочной. В последнем случае она может относиться не ко всем операциям и/или не ко всем пользователям (например, у уполномоченного пользователя может оставаться возможность выяснения идентификаторов пользователей). Псевдонимность. Напоминает анонимность, но при применении псевдонима поддерживается ссылка на идентификатор пользователя для обеспечения подотчетности или для других целей. Невозможность ассоциации. Семейство обеспечивает возможность неоднократного использования информационных сервисов, но не позволяет ассоциировать случаи использования между собой и приписать их одному лицу. Невозможность ассоциации защищает от построения профилей поведения пользователей (и, следовательно, от получения информации на основе подобных профилей). Скрытность. Требования данного семейства направлены на то, чтобы можно было использовать информационный сервис с сокрытием факта использования. Для реализации скрытности может применяться, например, широковещательное распространение информации, без указания конкретного адресата. Годятся для реализации скрытности и методы стеганографии, когда скрывается не только содержание сообщения (как в криптографии), но и сам факт его отправки. Еще один показательный (с нашей точки зрения) класс функциональных требований - "Использование ресурсов", содержащий требования доступности. Он включает три семейства. Отказоустойчивость. Требования этого семейства направлены на сохранение доступности информационных сервисов даже в случае сбоя или отказа. В ОК различаются активная и пассивная отказоустойчивость. Активный механизм содержит специальные функции, которые активизируются в случае сбоя. Пассивная отказоустойчивость подразумевает наличие избыточности с возможностью нейтрализации ошибок. Обслуживание по приоритетам. Выполнение этих требований позволяет управлять использованием ресурсов так, что низкоприоритетные операции не могут помешать высокоприоритетным. Распределение ресурсов. Требования направлены на защиту (путем применения механизма квот) от несанкционированной монополизации ресурсов. Мы видим, что "Общие критерии" - очень продуманный и полный документ с точки зрения функциональных требований. В то же время, хотелось бы обратить внимание и на некоторые недостатки. Первый мы уже отмечали - это отсутствие объектного подхода. Функциональные требования не сгруппированы в осмысленные наборы (объектные интерфейсы), к которым могло бы применяться наследование. Подобное положение, как известно из технологии программирования, чревато появлением слишком большого числа комбинаций функциональных компонентов, несопоставимых между собой. В современном программировании ключевым является вопрос накопления и многократного использования знаний. Стандарты - одна из форм накопления знаний. Следование в ОК "библиотечному", а не объектному подходу сужает круг фиксируемых знаний, усложняет их корректное использование. К сожалению, в "Общих критериях" отсутствуют архитектурные требования, что является естественным следствием избранного старомодного программистского подхода "снизу вверх". На наш взгляд, это серьезное упущение. Технологичность средств безопасности, следование общепризнанным рекомендациям по протоколам и программным интерфейсам, а также апробированным архитектурным решениям, таким как менеджер/агент, - необходимые качества изделий информационных технологий, предназначенных для поддержки критически важных функций, к числу которых, безусловно, относятся функции безопасности. Без рассмотрения интерфейсных аспектов системы оказываются нерасширяемыми и изолированными. Очевидно, с практической точки зрения это недопустимо. В то же время, обеспечение безопасности интерфейсов - важная задача, которую желательно решать единообразно. ​ Требования доверия безопасности Установление доверия безопасности, согласно "Общим критериям", основывается на активном исследовании объекта оценки. Форма представления требований доверия, в принципе, та же, что и для функциональных требований. Специфика состоит в том, что каждый элемент требований доверия принадлежит одному из трех типов: • действия разработчиков; • представление и содержание свидетельств; • действия оценщиков. Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы: • разработка (требования для поэтапной детализации функций безопасности от краткой спецификации до реализации); • поддержка жизненного цикла (требования к модели жизненного цикла, включая порядок устранения недостатков и защиту среды разработки); • тестирование; • оценка уязвимостей (включая оценку стойкости функций безопасности); • поставка и эксплуатация; • управление конфигурацией; • руководства (требования к эксплуатационной документации); • поддержка доверия (для поддержки этапов жизненного цикла после сертификации); • оценка профиля защиты; • оценка задания по безопасности. Применительно к требованиям доверия в "Общих критериях" сделана весьма полезная вещь, не реализованная, к сожалению, для функциональных требований. А именно, введены так называемые оценочные уровни доверия (их семь), содержащие осмысленные комбинации компонентов. Оценочный уровень доверия 1 (начальный) предусматривает анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации, а также независимое тестирование. Уровень применим, когда угрозы не рассматриваются как серьезные. Оценочный уровень доверия 2, в дополнение к первому уровню, предусматривает наличие проекта верхнего уровня объекта оценки, выборочное независимое тестирование, анализ стойкости функций безопасности, поиск разработчиком явных уязвимых мест. На третьем уровне ведется контроль среды разработки и управление конфигурацией объекта оценки. На уровне 4 добавляются полная спецификация интерфейсов, проекты нижнего уровня, анализ подмножества реализации, применение неформальной модели политики безопасности, независимый анализ уязвимых мест, автоматизация управления конфигурацией. Вероятно, это самый высокий уровень, которого можно достичь при существующей технологии программирования и приемлемых затратах. Уровень 5, в дополнение к предыдущим, предусматривает применение формальной модели политики безопасности, полуформальных функциональной спецификации и проекта верхнего уровня с демонстрацией соответствия между ними. Необходимо проведение анализа скрытых каналов разработчиками и оценщиками. На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня. Оценочный уровень 7 (самый высокий) предусматривает формальную верификацию проекта объекта оценки. Он применим к ситуациям чрезвычайно высокого риска. На этом мы заканчиваем краткий обзор "Общих критериев". ​ Гармонизированные критерии Европейских стран Наше изложение "Гармонизированных критериев" основывается на версии 1.2, опубликованной в июне 1991 года от имени соответствующих органов четырех стран - Франции, Германии, Нидерландов и Великобритании. Принципиально важной чертой Европейских Критериев является отсутствие требований к условиям, в которых должна работать информационная система. Так называемый спонсор, то есть организация, запрашивающая сертификационные услуги, формулирует цель оценки, то есть описывает условия, в которых должна работать система, возможные угрозы ее безопасности и предоставляемые ею защитные функции. Задача органа сертификации - оценить, насколько полно достигаются поставленные цели, то есть насколько корректны и эффективны архитектура и реализация механизмов безопасности в описанных спонсором условиях. Таким образом, в терминологии "Оранжевой книги", Европейские Критерии относятся к гарантированности безопасной работы системы. Требования к политике безопасности и наличию защитных механизмов не являются составной частью Критериев. Впрочем, чтобы облегчить формулировку цели оценки, Критерии содержат в качестве приложения описание десяти классов функциональности, типичных для правительственных и коммерческих систем. Европейские Критерии рассматривают все основные составляющие информационной безопасности - конфиденциальность, целостность, доступность. В Критериях проводится различие между системами и продуктами. Система - это конкретная аппаратно-программная конфигурация, построенная с вполне определенными целями и функционирующая в известном окружении. Продукт - это аппаратно-программный "пакет", который можно купить и по своему усмотрению встроить в ту или иную систему. Таким образом, с точки зрения информационной безопасности основное отличие между системой и продуктом состоит в том, что система имеет конкретное окружение, которое можно определить и изучить сколь угодно детально, а продукт должен быть рассчитан на использование в различных условиях. Из практических соображений важно обеспечить единство критериев оценки продуктов и систем - например, чтобы облегчить оценку системы, составленной из ранее сертифицированных продуктов. По этой причине для систем и продуктов вводится единый термин - объект оценки. Каждая система и/или продукт предъявляет свои требования к обеспечению конфиденциальности, целостности и доступности. Чтобы удовлетворить эти требования, необходимо предоставить соответствующий набор функций (сервисов) безопасности, таких как идентификация и аутентификация, управление доступом или восстановление после сбоев. Сервисы безопасности реализуются посредством конкретных механизмов. Чтобы объекту оценки можно было доверять, необходима определенная степень уверенности в наборе функций и механизмов безопасности. Степень уверенности мы будем называть гарантированностью. Гарантированность может быть большей или меньшей в зависимости от тщательности проведения оценки. Гарантированность затрагивает два аспекта - эффективность и корректность средств безопасности. При проверке эффективности анализируется соответствие между целями, сформулированными для объекта оценки, и имеющимся набором функций безопасности. Точнее говоря, рассматриваются вопросы адекватности функциональности, взаимной согласованности функций, простоты их использования, а также возможные последствия эксплуатации известных слабых мест защиты. Кроме того, в понятие эффективности входит способность механизмов защиты противостоять прямым атакам (мощность механизма). Определяются три градации мощности - базовая, средняя и высокая. Под корректностью понимается правильность реализации функций и механизмов безопасности. В Критериях определяется семь возможных уровней гарантированности корректности - от E0 до E6 (в порядке возрастания). Уровень E0 означает отсутствие гарантированности. При проверке корректности анализируется весь жизненный цикл объекта оценки - от проектирования до эксплуатации и сопровождения. Общая оценка системы складывается из минимальной мощности механизмов безопасности и уровня гарантированности корректности. Гармонизированные критерии Европейских стран явились для своего времени весьма передовым стандартом, они создали предпосылки для появления "Общих критериев". ​ Интерпретация "Оранжевой книги" для сетевых конфигураций В 1987 году Национальным центром компьютерной безопасности США была опубликована интерпретация "Оранжевой книги" для сетевых конфигураций. Данный документ состоит из двух частей. Первая содержит собственно интерпретацию, во второй рассматриваются сервисы безопасности, специфичные или особенно важные для сетевых конфигураций. В первой части вводится минимум новых понятий. Важнейшее из них - сетевая доверенная вычислительная база, распределенный аналог доверенной вычислительной базы изолированных систем. Сетевая доверенная вычислительная база формируется из всех частей всех компонентов сети, обеспечивающих информационную безопасность. Доверенная сетевая система должна обеспечивать такое распределение защитных механизмов, чтобы общая политика безопасности реализовывалась, несмотря на уязвимость коммуникационных путей и на параллельную, асинхронную работу компонентов. Прямой зависимости между вычислительными базами компонентов, рассматриваемых как изолированные системы, и фрагментами сетевой вычислительной базы не существует. Более того, нет прямой зависимости и между уровнями безопасности отдельных компонентов и уровнем безопасности всей сетевой конфигурации. Например, в результате объединения двух систем класса B1, обладающих несовместимыми правилами кодирования меток безопасности, получается сеть, не удовлетворяющая требованию целостности меток. В качестве противоположного примера рассмотрим объединение двух компонентов, один из которых сам не обеспечивает протоколирование действий пользователя, но передает необходимую информацию другому компоненту, который и ведет протокол. В таком случае распределенная система в целом, несмотря на слабость компонента, удовлетворяет требованию подотчетности. Чтобы понять суть положений, вошедших в первую часть, рассмотрим интерпретацию требований к классу безопасности C2. Первое требование к этому классу - поддержка произвольного управления доступом. Интерпретация предусматривает различные варианты распределения сетевой доверенной вычислительной базы по компонентам и, соответственно, различные варианты распределения механизмов управления доступом. В частности, некоторые компоненты, закрытые для прямого доступа пользователей, могут вообще не содержать подобных механизмов. Интерпретация отличается от самих "Критериев" учетом динамичности сетевых конфигураций. Предусматривается наличие средств проверки подлинности и корректности функционирования компонентов перед их включением в сеть, наличие протокола взаимной проверки компонентами корректности функционирования друг друга, а также присутствие средств оповещения администратора о неполадках в сети. Сетевая конфигурация должна быть устойчива к отказам отдельных компонентов или коммуникационных путей. Среди защитных механизмов в сетевых конфигурациях на первом месте стоит криптография, помогающая поддерживать как конфиденциальность, так и целостность. Следствием использования криптографических методов является необходимость реализации механизмов управления ключами. Систематическое рассмотрение вопросов доступности является новшеством по сравнению не только с "Оранжевой книгой", но и с рекомендациями X.800. Сетевой сервис перестает быть доступным, когда пропускная способность коммуникационных каналов падает ниже минимально допустимого уровня или сервис не в состоянии обслуживать запросы. Удаленный ресурс может стать недоступным и вследствие нарушения равноправия в обслуживании пользователей. Доверенная система должна иметь возможность обнаруживать ситуации недоступности, уметь возвращаться к нормальной работе и противостоять атакам на доступность. Для обеспечения непрерывности функционирования могут применяться следующие защитные меры: • внесение в конфигурацию той или иной формы избыточности (резервное оборудование, запасные каналы связи и т.п.); • наличие средств реконфигурирования для изоляции и/или замены узлов или коммуникационных каналов, отказавших или подвергшихся атаке на доступность; • рассредоточенность сетевого управления, отсутствие единой точки отказа; • наличие средств нейтрализации отказов (обнаружение отказавших компонентов, оценка последствий, восстановление после отказов); • выделение подсетей и изоляция групп пользователей друг от друга. Одним из важнейших в "Оранжевой книге" является понятие монитора обращений. Применительно к структурированию сетевой конфигурации можно сформулировать следующее утверждение, обеспечивающее достаточное условие корректности фрагментирования монитора обращений. Пусть каждый субъект (то есть процесс, действующий от имени какого-либо пользователя) заключен внутри одного компонента и может осуществлять непосредственный доступ к объектам только в пределах этого компонента. Далее, пусть каждый компонент содержит свой монитор обращений, отслеживающий все локальные попытки доступа, и все мониторы реализуют согласованную политику безопасности. Пусть, наконец, коммуникационные каналы, связывающие компоненты, сохраняют конфиденциальность и целостность передаваемой информации. Тогда совокупность всех мониторов образует единый монитор обращений для всей сетевой конфигурации. Данное утверждение является теоретической основой декомпозиции распределенной ИС в объектно-ориентированном стиле в сочетании с криптографической защитой коммуникаций. ​ Руководящие документы Гостехкомиссии России Гостехкомиссия России в период своего существования вела весьма активную нормотворческую деятельность, выпуская Руководящие документы (РД), играющие роль национальных оценочных стандартов в области информационной безопасности. В качестве стратегического направления Гостехкомиссия России выбрала ориентацию на "Общие критерии", что можно только приветствовать. В своем обзоре мы рассмотрим два важных, хотя и не новых, Руководящих документа - Классификацию автоматизированных систем (АС) по уровню защищенности от несанкционированного доступа (НСД) и аналогичную Классификацию межсетевых экранов (МЭ). Согласно первому из них, устанавливается девять классов защищенности АС от НСД к информации. Каждый класс характеризуется определенной минимальной совокупностью требований по защите. Классы подразделяются на три группы, отличающиеся особенностями обработки информации в АС. В пределах каждой группы соблюдается иерархия требований по защите в зависимости от ценности (конфиденциальности) информации и, следовательно, иерархия классов защищенности АС. Третья группа классифицирует АС, в которых работает один пользователь, имеющий доступ ко всей информации АС, размещенной на носителях одного уровня конфиденциальности. Группа содержит два класса - 3Б и 3А. Вторая группа классифицирует АС, в которых пользователи имеют одинаковые права доступа (полномочия) ко всей информации АС, обрабатываемой и (или) хранящейся на носителях различного уровня конфиденциальности. Группа содержит два класса - 2Б и 2А. Первая группа классифицирует многопользовательские АС, в которых одновременно обрабатывается и (или) хранится информация разных уровней конфиденциальности и не все пользователи имеют право доступа ко всей информации АС. Группа содержит пять классов - 1Д, 1Г, 1В, 1Б и 1А. Сведем в таблицу требования ко всем девяти классам защищенности АС. Таблица 2.3. Требования к защищенности автоматизированных систем Подсистемы и требования Классы 3Б 3А 2Б 2А 1Д 1Г 1В 1Б 1А 1. Подсистема управления доступом 1.1. Идентификация, проверка подлинности и контроль доступа субъектов: в систему; + + + + + + + + + к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ; - - - + - + + + + к программам; - - - + - + + + + к томам, каталогам, файлам, записям, полям записей. - - - + - + + + + 1.2. Управление потоками информации - - - + - - + + + 2. Подсистема регистрации и учета 2.1. Регистрация и учет: входа/выхода субъектов доступа в/из системы (узла сети); + + + + + + + + + выдачи печатных (графических) выходных документов; - + - + - + + + + запуска/завершения программ и процессов (заданий, задач); - - - + - + + + + доступа программ субъектов доступа к терминалам, ЭВМ, узлам сети ЭВМ, каналам связи, внешним устройствам ЭВМ, программам, томам, каталогам, файлам, записям, полям записей; - - - + - + + + + изменения полномочий субъектов доступа; - - - - - - + + + создаваемых защищаемых объектов доступа. - - - + - - + + + 2.2. Учет носителей информации. + + + + + + + + + 2.3. Очистка (обнуление, обезличивание) освобождаемых областей оперативной памяти ЭВМ и внешних накопителей. - + - + - + + + + 2.4. Сигнализация попыток нарушения защиты. - - - - - - + + + 3. Криптографическая подсистема 3.1. Шифрование конфиденциальной информации. - - - + - - - + + 3.2. Шифрование информации, принадлежащей различным субъектам доступа (группам субъектов) на разных ключах. - - - - - - - - + 3.3. Использование аттестованных (сертифицированных) криптографических средств. - - - + - - - + + 4. Подсистема обеспечения целостности 4.1. Обеспечение целостности программных средств и обрабатываемой информации. + + + + + + + + + 4.2. Физическая охрана средств вычислительной техники и носителей информации. + + + + + + + + + 4.3. Наличие администратора (службы защиты) информации в АС. - - - + - - + + + 4.4. Периодическое тестирование СЗИ НСД. + + + + + + + + + 4.5. Наличие средств восстановления СЗИ НСД. + + + + + + + + + 4.6. Использование сертифицированных средств защиты. - + - + - - + + + "-" нет требований к данному классу; "+" есть требования к данному классу; "СЗИ НСД" система защиты информации от несанкционированного доступа По существу перед нами - минимум требований, которым необходимо следовать, чтобы обеспечить конфиденциальность информации. Целостность представлена отдельной подсистемой (номер 4), но непосредственно к интересующему нас предмету имеет отношение только пункт 4.1. Доступность (точнее, восстановление) предусмотрено только для самих средств защиты. Переходя к рассмотрению второго РД Гостехкомиссии России - Классификации межсетевых экранов - укажем, что данный РД представляется нам принципиально важным, поскольку в нем идет речь не о целостном продукте или системе, а об отдельном сервисе безопасности, обеспечивающем межсетевое разграничение доступа. Данный РД важен не столько содержанием, сколько самим фактом своего существования. Основным критерием классификации МЭ служит протокольный уровень (в соответствии с эталонной семиуровневой моделью), на котором осуществляется фильтрация информации. Это понятно: чем выше уровень, тем больше информации на нем доступно и, следовательно, тем более тонкую и надежную фильтрацию можно реализовать. Значительное внимание в РД уделено собственной безопасности служб обеспечения защиты и вопросам согласованного администрирования распределенных конфигураций. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Перечислите руководящие документы Гостехкомиссии России 2.Поясните что такое "Оранжевой книги" для сетевых конфигураций 3.Перечислите требования доверия безопасности 4.Опишите стандарт ISO/IEC 15408 "Критерии оценки безопасности информационных технологий" 5.Опишите процесс администрирование средств безопасности ЛЕКЦИЯ 3. АДМИНИСТРАТИВНЫЙ И ПРОЦЕДУРНЫЙ УРОВНИ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТИ Основные классы мер процедурного уровня Мы приступаем к рассмотрению мер безопасности, которые ориентированы на людей, а не на технические средства. Именно люди формируют режим информационной безопасности, и они же оказываются главной угрозой, поэтому "человеческий фактор" заслуживает особого внимания. В российских компаниях накоплен богатый опыт регламентирования и реализации процедурных (организационных) мер, однако дело в том, что они пришли из "докомпьютерного" прошлого, поэтому требуют переоценки. Следует осознать ту степень зависимости от компьютерной обработки данных, в которую попало современное общество. Без всякого преувеличения можно сказать, что необходима информационная гражданская оборона. Спокойно, без нагнетания страстей, нужно разъяснять обществу не только преимущества, но и опасности, связанные с использованием информационных технологий. Акцент следует делать не на военной или криминальной стороне дела, а на гражданских аспектах, связанных с поддержанием нормального функционирования аппаратного и программного обеспечения, то есть концентрироваться на вопросах доступности и целостности данных. На процедурном уровне можно выделить следующие классы мер: • управление персоналом; • физическая защита; • поддержание работоспособности; • реагирование на нарушения режима безопасности; • планирование восстановительных работ. Управление персоналом Управление персоналом начинается с приема нового сотрудника на работу и даже раньше - с составления описания должности. Уже на данном этапе желательно подключить к работе специалиста по информационной безопасности для определения компьютерных привилегий, ассоциируемых с должностью. Существует два общих принципа, которые следует иметь в виду: • разделение обязанностей; • минимизация привилегий. Принцип разделения обязанностей предписывает как распределять роли и ответственность, чтобы один человек не мог нарушить критически важный для организации процесс. Например, нежелательна ситуация, когда крупные платежи от имени организации выполняет один человек. Надежнее поручить одному сотруднику оформление заявок на подобные платежи, а другому - заверять эти заявки. Другой пример - процедурные ограничения действий суперпользователя. Можно искусственно "расщепить" пароль суперпользователя, сообщив первую его часть одному сотруднику, а вторую - другому. Тогда критически важные действия по администрированию ИС они смогут выполнить только вдвоем, что снижает вероятность ошибок и злоупотреблений. Принцип минимизации привилегий предписывает выделять пользователям только те права доступа, которые необходимы им для выполнения служебных обязанностей. Назначение этого принципа очевидно - уменьшить ущерб от случайных или умышленных некорректных действий. Предварительное составление описания должности позволяет оценить ее критичность и спланировать процедуру проверки и отбора кандидатов. Чем ответственнее должность, тем тщательнее нужно проверять кандидатов: навести о них справки, быть может, побеседовать с бывшими сослуживцами и т.д. Подобная процедура может быть длительной и дорогой, поэтому нет смысла дополнительно усложнять ее. В то же время, неразумно и совсем отказываться от предварительной проверки, чтобы случайно не принять на работу человека с уголовным прошлым или психическим заболеванием. Когда кандидат определен, он, вероятно, должен пройти обучение ; по крайней мере, его следует подробно ознакомить со служебными обязанностями, а также с нормами и процедурами информационной безопасности. Желательно, чтобы меры безопасности были им усвоены до вступления в должность и до заведения его системного счета с входным именем, паролем и привилегиями. С момента заведения системного счета начинается его администрирование, а также протоколирование и анализ действий пользователя. Постепенно изменяется окружение, в котором работает пользователь, его служебные обязанности и т.п. Все это требует соответствующего изменения привилегий. Техническую сложность представляют временные перемещения пользователя, выполнение им обязанностей взамен сотрудника, ушедшего в отпуск, и иные обстоятельства, когда полномочия нужно сначала предоставить, а через некоторое время взять обратно. В такие периоды профиль активности пользователя резко меняется, что создает трудности при выявлении подозрительных ситуаций. Определенную аккуратность следует соблюдать и при выдаче новых постоянных полномочий, не забывая ликвидировать старые права доступа. Ликвидация системного счета пользователя, особенно в случае конфликта между сотрудником и организацией, должна производиться максимально оперативно (в идеале - одновременно с извещением о наказании или увольнении). Возможно и физическое ограничение доступа к рабочему месту. Разумеется, если сотрудник увольняется, у него нужно принять все его компьютерное хозяйство и, в частности, криптографические ключи, если использовались средства шифрования. К управлению сотрудниками примыкает администрирование лиц, работающих по контракту (например, специалистов фирмы-поставщика, помогающих запустить новую систему). В соответствии с принципом минимизации привилегий, им нужно выделить ровно столько прав, сколько необходимо, и изъять эти права сразу по окончании контракта. Проблема, однако, состоит в том, что на начальном этапе внедрения "внешние" сотрудники будут администрировать "местных", а не наоборот. Здесь на первый план выходит квалификация персонала организации, его способность быстро обучаться, а также оперативное проведение учебных курсов. Важны и принципы выбора деловых партнеров. Иногда внешние организации принимают на обслуживание и администрирование ответственные компоненты компьютерной системы, например, сетевое оборудование. Нередко администрирование выполняется в удаленном режиме. Вообще говоря, это создает в системе дополнительные уязвимые места, которые необходимо компенсировать усиленным контролем средств удаленного доступа или, опять-таки, обучениемсобственных сотрудников. Мы видим, что проблема обучения - одна из основных с точки зрения информационной безопасности. Если сотрудник не знаком с политикой безопасности своей организации, он не может стремиться к достижению сформулированных в ней целей. Не зная мер безопасности, он не сможет их соблюдать. Напротив, если сотрудник знает, что его действия протоколируются, он, возможно, воздержится от нарушений. Физическая защита Безопасность информационной системы зависит от окружения, в котором она функционирует. Необходимо принять меры для защиты зданий и прилегающей территории, поддерживающей инфраструктуры, вычислительной техники, носителей данных. Основной принцип физической защиты, соблюдение которого следует постоянно контролировать, формулируется как "непрерывность защиты в пространстве и времени". Ранее мы рассматривали понятие окна опасности. Для физической защиты таких окон быть не должно. Мы кратко рассмотрим следующие направления физической защиты: • физическое управление доступом; • противопожарные меры; • защита поддерживающей инфраструктуры; • защита от перехвата данных; • защита мобильных систем. Меры физического управления доступом позволяют контролировать и при необходимости ограничивать вход и выход сотрудников и посетителей. Контролироваться может все здание организации, а также отдельные помещения, например, те, где расположены серверы, коммуникационная аппаратура и т.п. При проектировании и реализации мер физического управления доступом целесообразно применять объектный подход. Во-первых, определяется периметр безопасности, ограничивающий контролируемую территорию. На этом уровне детализации важно продумать внешний интерфейс организации - порядок входа/выхода штатных сотрудников и посетителей, вноса/выноса техники. Все, что не входит во внешний интерфейс, должно быть инкапсулировано, то есть защищено от нелегальных проникновений. Во-вторых, производится декомпозиция контролируемой территории, выделяются (под)объекты и связи (проходы) между ними. При такой, более глубокой детализации следует выделить среди подобъектов наиболее критичные с точки зрения безопасности и обеспечить им повышенное внимание. Декомпозиция должна быть семантически оправданной, обеспечивающей разграничение разнородных сущностей, таких как оборудование разных владельцев или персонал, работающий с данными разной степени критичности. Важно сделать так, чтобы посетители, по возможности, не имели непосредственного доступа к компьютерам или, в крайнем случае, позаботиться о том, чтобы от окон и дверей не просматривались экраны мониторов и принтеры. Необходимо, чтобы посетителей по внешнему виду можно было отличить от сотрудников. Если отличие состоит в том, что посетителям выдаются идентификационные карточки, а сотрудники ходят "без опознавательных знаков", злоумышленнику достаточно снять карточку, чтобы его считали "своим". Очевидно, соответствующие карточки нужно выдавать всем. Средства физического управления доступом известны давно. Это охрана, двери с замками, перегородки, телекамеры, датчики движения и многое другое. Для выбора оптимального (по критерию стоимость/эффективность) средства целесообразно провести анализ рисков (к этому мы еще вернемся). Кроме того, есть смысл периодически отслеживать появление технических новинок в данной области, стараясь максимально автоматизировать физическую защиту. Более подробно данная тема рассмотрена в статье В. Барсукова "Физическая защита информационных систем" (Jet Info, 1997, 1). Профессия пожарного - одна из древнейших, но пожары по-прежнему случаются и наносят большой ущерб. Мы не собираемся цитировать параграфы противопожарных инструкций или изобретать новые методы борьбы с огнем - на это есть профессионалы. Отметим лишь необходимость установки противопожарной сигнализации и автоматических средств пожаротушения. Обратим также внимание на то, что защитные меры могут создавать новые слабые места. Если на работу взят новый охранник, это, вероятно, улучшает физическое управление доступом. Если же он по ночам курит и пьет, то ввиду повышенной пожароопасности подобная мера защиты может только навредить. К поддерживающей инфраструктуре можно отнести системы электро-, водо- и теплоснабжения, кондиционеры и средства коммуникаций. В принципе, к ним применимы те же требования целостности и доступности, что и к информационным системам. Для обеспечения целостности нужно защищать оборудование от краж и повреждений. Для поддержания доступности следует выбирать оборудование с максимальным временем наработки на отказ, дублировать ответственные узлы и всегда иметь под рукой запчасти. Отдельную проблему составляют аварии водопровода. Они происходят нечасто, но могут нанести огромный ущерб. При размещении компьютеров необходимо принять во внимание расположение водопроводных и канализационных труб и постараться держаться от них подальше. Сотрудники должны знать, куда следует обращаться при обнаружении протечек. Перехват данных (о чем мы уже писали) может осуществляться самыми разными способами. Злоумышленник может подсматривать за экраном монитора, читать пакеты, передаваемые по сети, производить анализ побочных электромагнитных излучений и наводок (ПЭМИН) и т.д. Остается уповать на повсеместное использование криптографии (что, впрочем, сопряжено у нас в стране со множеством технических и законодательных проблем), стараться максимально расширить контролируемую территорию, разместившись в тихом особнячке, поодаль от других домов, пытаться держать под контролем линии связи (например, заключать их в надувную оболочку с обнаружением прокалывания), но самое разумное, вероятно, - постараться осознать, что для коммерческих систем обеспечение конфиденциальности является все-таки не главной задачей. Желающим подробнее ознакомиться с вопросом мы рекомендуем прочитать статью В. Барсукова "Блокирование технологических каналов утечки информации" (Jet Info, 1998, 5-6). Мобильные и портативные компьютеры - заманчивый объект кражи. Их часто оставляют без присмотра, в автомобиле или на работе, и похитить такой компьютер совсем несложно. То и дело средства массовой информации сообщают о том, что какой-нибудь офицер английской разведки или американский военный лишился таким образом движимого имущества. Мы настоятельно рекомендуем шифровать данные на жестких дисках таких компьютеров. Вообще говоря, при выборе средств физической защиты следует производить анализ рисков. Так, принимая решение о закупке источника бесперебойного питания, необходимо учесть качество электропитания в здании, занимаемом организацией (впрочем, почти наверняка оно окажется плохим), характер и длительность сбоев электропитания, стоимость доступных источников и возможные потери от аварий (поломка техники, приостановка работы организации и т.п.) (см. также статью В.Барсукова "Защита компьютерных систем от силовых деструктивных воздействий" в Jet Info, 2000, 2). В то же время, во многих случаях решения очевидны. Меры противопожарной безопасности обязательны для всех организаций. Стоимость реализации многих мер (например, установка обычного замка на дверь серверной комнаты) либо мала, либо хоть и заметна, но все же явно меньше, чем возможный ущерб. В частности, имеет смысл регулярно копировать большие базы данных. Поддержание работоспособности Далее рассмотрим ряд рутинных мероприятий, направленных на поддержание работоспособности информационных систем. Именно здесь таится наибольшая опасность. Нечаянные ошибки системных администраторов и пользователей грозят повреждением аппаратуры, разрушением программ и данных; в лучшем случае они создают бреши в защите, которые делают возможной реализацию угроз. Недооценка факторов безопасности в повседневной работе - ахиллесова пята многих организаций. Дорогие средства безопасности теряют смысл, если они плохо документированы, конфликтуют с другим программным обеспечением, а пароль системного администратора не менялся с момента установки. Можно выделить следующие направления повседневной деятельности: • поддержка пользователей; • поддержка программного обеспечения; • конфигурационное управление; • резервное копирование; • управление носителями; • документирование; • регламентные работы. Поддержка пользователей подразумевает прежде всего консультирование и оказание помощи при решении разного рода проблем. Иногда в организациях создают для этой цели специальный "справочный стол", но чаще от пользователей отбивается системный администратор. Очень важно в потоке вопросов уметь выявлять проблемы, связанные с информационной безопасностью. Так, многие трудности пользователей, работающих на персональных компьютерах, могут быть следствием заражения вирусами. Целесообразно фиксировать вопросы пользователей, чтобы выявлять их типичные ошибки и выпускать памятки с рекомендациями для распространенных ситуаций. Поддержка программного обеспечения - одно из важнейших средств обеспечения целостности информации. Прежде всего, необходимо следить за тем, какое программное обеспечение установлено на компьютерах. Если пользователи будут устанавливать программы по своему усмотрению, это может привести к заражению вирусами, а также появлению утилит, действующих в обход защитных средств. Вполне вероятно также, что "самодеятельность" пользователей постепенно приведет к хаосу на их компьютерах, а исправлять ситуацию придется системному администратору. Второй аспект поддержки программного обеспечения - контроль за отсутствием неавторизованного изменения программ и прав доступа к ним. Сюда же можно отнести поддержку эталонных копий программных систем. Обычно контроль достигается комбинированием средств физического и логического управления доступом, а также использованием утилит проверки и обеспечения целостности. Конфигурационное управление позволяет контролировать и фиксировать изменения, вносимые в программную конфигурацию. Прежде всего, необходимо застраховаться от случайных или непродуманных модификаций, уметь как минимум возвращаться к прошлой, работающей, версии. Фиксация изменений позволит легко восстановить текущую версию после аварии. Лучший способ уменьшить количество ошибок в рутинной работе - максимально автоматизировать ее. Правы те "ленивые" программисты и системные администраторы, которые, окинув взглядом море однообразных задач, говорят: "Я ни за что не буду делать этого; я напишу программу, которая сделает все за меня". Автоматизация и безопасность зависят друг от друга; тот, кто заботится в первую очередь об облегчении своей задачи, на самом деле оптимальным образом формирует режим информационной безопасности. Резервное копирование необходимо для восстановления программ и данных после аварий. И здесь целесообразно автоматизировать работу, как минимум, сформировав компьютерное расписание создания полных и инкрементальных копий, а как максимум - воспользовавшись соответствующими программными продуктами (см., например, Jet Info, 2000, 12). Нужно также наладить размещение копий в безопасном месте, защищенном от несанкционированного доступа, пожаров, протечек, то есть от всего, что может привести к краже или повреждению носителей. Целесообразно иметь несколько экземпляров резервных копий и часть из них хранить вне территории организации, защищаясь таким образом от крупных аварий и аналогичных инцидентов. Время от времени в тестовых целях следует проверять возможность восстановления информации с копий. Управлять носителями необходимо для обеспечения физической защиты и учета дискет, лент, печатных выдач и т.п. Управление носителями должно обеспечивать конфиденциальность, целостность и доступность информации, хранящейся вне компьютерных систем. Под физической защитой здесь понимается не только отражение попыток несанкционированного доступа, но и предохранение от вредных влияний окружающей среды (жары, холода, влаги, магнетизма). Управление носителями должно охватывать весь жизненный цикл - от закупки до выведения из эксплуатации. Документирование - неотъемлемая часть информационной безопасности. В виде документов оформляется почти все - от политики безопасности до журнала учета носителей. Важно, чтобы документация была актуальной, отражала именно текущее состояние дел, причем в непротиворечивом виде. К хранению одних документов (содержащих, например, анализ уязвимых мест системы и угроз) применимы требования обеспечения конфиденциальности, к другим, таким как план восстановления после аварий - требования целостности и доступности (в критической ситуации план необходимо найти и прочитать). Регламентные работы - очень серьезная угроза безопасности. Сотрудник, осуществляющий регламентные работы, получает исключительный доступ к системе, и на практике очень трудно проконтролировать, какие именно действия он совершает. Здесь на первый план выходит степень доверия к тем, кто выполняет работу. Реагирование на нарушения режима безопасности Программа безопасности, принятая организацией, должна предусматривать набор оперативных мероприятий, направленных на обнаружение и нейтрализацию нарушений режима информационной безопасности. Важно, чтобы в подобных случаях последовательность действий была спланирована заранее, поскольку меры нужно принимать срочные и скоординированные. Реакция на нарушения режима безопасности преследует три главные цели: • локализация инцидента и уменьшение наносимого вреда; • выявление нарушителя; • предупреждение повторных нарушений. В организации должен быть человек, доступный 24 часа в сутки (лично, по телефону, пейджеру или электронной почте), который отвечает за реакцию на нарушения. Все должны знать координаты этого человека и обращаться к нему при первых признаках опасности. В общем, как при пожаре, нужно знать, куда звонить, и что делать до приезда пожарной команды. Важность быстрой и скоординированной реакции можно продемонстрировать на следующем примере. Пусть локальная сеть предприятия состоит из двух сегментов, администрируемых разными людьми. Далее, пусть в один из сегментов был внесен вирус. Почти наверняка через несколько минут (или, в крайнем случае, несколько десятков минут) вирус распространится и на другой сегмент. Значит, меры нужно принять немедленно. "Вычищать" вирус необходимо одновременно в обоих сегментах; в противном случае сегмент, восстановленный первым, заразится от другого, а затем вирус вернется и во второй сегмент. Нередко требование локализации инцидента и уменьшения наносимого вреда вступает в конфликт с желанием выявить нарушителя. В политике безопасности организации приоритеты должны быть расставлены заранее. Поскольку, как показывает практика, выявить злоумышленника очень сложно, на наш взгляд, в первую очередь следует заботиться об уменьшении ущерба. Чтобы найти нарушителя, нужно заранее выяснить контактные координаты поставщика сетевых услуг и договориться с ним о самой возможности и порядке выполнения соответствующих действий. Более подробно данная тема рассматривается в статье Н. Браунли и Э. Гатмэна "Как реагировать на нарушения информационной безопасности (RFC 2350, BCP 21)" (Jet Info, 2000, 5). Чтобы предотвратить повторные нарушения, необходимо анализировать каждый инцидент, выявлять причины, накапливать статистику. Каковы источники вредоносного ПО? Какие пользователи имеют обыкновение выбирать слабые пароли? На подобные вопросы и должны дать ответ результаты анализа. Необходимо отслеживать появление новых уязвимых мест и как можно быстрее ликвидировать ассоциированные с ними окна опасности. Кто-то в организации должен курировать этот процесс, принимать краткосрочные меры и корректировать программу безопасности для принятия долгосрочных мер. Планирование восстановительных работ Ни одна организация не застрахована от серьезных аварий, вызванных естественными причинами, действиями злоумышленника, халатностью или некомпетентностью. В то же время, у каждой организации есть функции, которые руководство считает критически важными, они должны выполняться несмотря ни на что. Планирование восстановительных работ позволяет подготовиться к авариям, уменьшить ущерб от них и сохранить способность к функционированию хотя бы в минимальном объеме. Отметим, что меры информационной безопасности можно разделить на три группы, в зависимости от того, направлены ли они на предупреждение, обнаружение или ликвидацию последствий атак. Большинство мер носит предупредительный характер. Оперативный анализрегистрационной информации и некоторые аспекты реагирования на нарушения (так называемый активный аудит) служат для обнаружения и отражения атак. Планирование восстановительных работ, очевидно, можно отнести к последней из трех перечисленных групп. Процесс планирования восстановительных работ можно разделить на следующие этапы: • выявление критически важных функций организации, установление приоритетов; • идентификация ресурсов, необходимых для выполнения критически важных функций; • определение перечня возможных аварий; • разработка стратегии восстановительных работ; • подготовка к реализации выбранной стратегии; • проверка стратегии. Планируя восстановительные работы, следует отдавать себе отчет в том, что полностью сохранить функционирование организации не всегда возможно. Необходимо выявить критически важные функции, без которых организация теряет свое лицо, и даже среди критичных функций расставить приоритеты, чтобы как можно быстрее и с минимальными затратами возобновить работу после аварии. Идентифицируя ресурсы, необходимые для выполнения критически важных функций, следует помнить, что многие из них имеют некомпьютерный характер. На данном этапе желательно подключать к работе специалистов разного профиля, способных в совокупности охватить все аспекты проблемы. Критичные ресурсы обычно относятся к одной из следующих категорий: • персонал; • информационная инфраструктура; • физическая инфраструктура. Составляя списки ответственных специалистов, следует учитывать, что некоторые из них могут непосредственно пострадать от аварии (например, от пожара), кто-то может находиться в состоянии стресса, часть сотрудников, возможно, будет лишена возможности попасть на работу (например, в случае массовых беспорядков). Желательно иметь некоторый резерв специалистов или заранее определить каналы, покоторым можно на время привлечь дополнительный персонал. Информационная инфраструктура включает в себя следующие элементы: • компьютеры; • программы и данные; • информационные сервисы внешних организаций; • документацию. Нужно подготовиться к тому, что на "запасном аэродроме", куда организация будет эвакуирована после аварии, аппаратная платформа может отличаться от исходной. Соответственно, следует продумать меры поддержания совместимости по программам и данным. Среди внешних информационных сервисов для коммерческих организаций, вероятно, важнее всего получить оперативную информацию и связьс государственными службами, курирующими данный сектор экономики. Документация важна хотя бы потому, что не вся информация, с которой работает организация, представлена в электронном виде. Скорее всего, план восстановительных работ напечатан на бумаге. К физической инфраструктуре относятся здания, инженерные коммуникации, средства связи, оргтехника и многое другое. Компьютерная техника не может работать в плохих условиях, без стабильного электропитания и т.п. Анализируя критичные ресурсы, целесообразно учесть временной профиль их использования. Большинство ресурсов требуются постоянно, но в некоторых нужда может возникать только в определенные периоды (например, в конце месяца или года при составлении отчета). При определении перечня возможных аварий нужно попытаться разработать их сценарии. Как будут развиваться события? Каковы могут оказаться масштабы бедствия? Что произойдет с критичными ресурсами? Например, смогут ли сотрудники попасть на работу? Будут ли выведены из строя компьютеры? Возможны ли случаи саботажа? Будет ли работать связь? Пострадает ли здание организации? Можно ли будет найти и прочитать необходимые бумаги? Стратегия восстановительных работ должна базироваться на наличных ресурсах и быть не слишком накладной для организации. При разработке стратегии целесообразно провести анализ рисков, которым подвергаются критичные функции, и попытаться выбрать наиболее экономичное решение. Стратегия должна предусматривать не только работу по временной схеме, но и возвращение к нормальному функционированию. Подготовка к реализации выбранной стратегии состоит в выработке плана действий в экстренных ситуациях и по их окончании, а также в обеспечении некоторой избыточности критичных ресурсов. Последнее возможно и без большого расхода средств, если заключить с одной или несколькими организациями соглашения о взаимной поддержке в случае аварий - те, кто не пострадал, предоставляют часть своих ресурсов во временное пользование менее удачливым партнерам. Избыточность обеспечивается также мерами резервного копирования, хранением копий в нескольких местах, представлением информации в разных видах (на бумаге и в файлах) и т.д. Имеет смысл заключить соглашение с поставщиками информационных услуг о первоочередном обслуживании в критических ситуациях или заключать соглашения с несколькими поставщиками. Правда, эти меры могут потребовать определенных расходов. Проверка стратегии производится путем анализа подготовленного плана, принятых и намеченных мер. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Охарактеризуйте планирование восстановительных работ 2.Перечислите основные классы мер процедурного уровня 3. Опишите как происходит управление персоналом 4.На чем основана физическая защита информации 5.Перечислите основные моменты реагирование на нарушения режима безопасности ЛЕКЦИЯ 4. ОСНОВНЫЕ ПРОГРАММНО-ТЕХНИЧЕСКИЕ МЕРЫ Основные понятия программно-технического уровня информационной безопасности Программно-технические меры, то есть меры, направленные на контроль компьютерных сущностей - оборудования, программ и/или данных, образуют последний и самый важный рубеж информационной безопасности. Напомним, что ущерб наносят в основном действия легальных пользователей, по отношению к которым процедурные регуляторы малоэффективны. Главные враги - некомпетентность и неаккуратность при выполнении служебных обязанностей, и только программно-технические меры способны им противостоять. Компьютеры помогли автоматизировать многие области человеческой деятельности. Вполне естественным представляется желание возложить на них и обеспечение собственной безопасности. Даже физическую защиту все чаще поручают не охранникам, а интегрированным компьютерным системам, что позволяет одновременно отслеживать перемещения сотрудников и по организации, и по информационному пространству. Это вторая причина, объясняющая важность программно-технических мер. Следует, однако, учитывать, что быстрое развитие информационных технологий не только предоставляет обороняющимся новые возможности, но и объективно затрудняет обеспечение надежной защиты, если опираться исключительно на меры программно-технического уровня. Причин тому несколько: • повышение быстродействия микросхем, развитие архитектур с высокой степенью параллелизма позволяет методом грубой силы преодолевать барьеры (прежде всего криптографические), ранее казавшиеся неприступными; • развитие сетей и сетевых технологий, увеличение числа связей между информационными системами, рост пропускной способности каналов расширяют круг злоумышленников, имеющих техническую возможность организовывать атаки; • появление новых информационных сервисов ведет и к образованию новых уязвимых мест как "внутри" сервисов, так и на их стыках; • конкуренция среди производителей программного обеспечения заставляет сокращать сроки разработки, что приводит к снижению качества тестирования и выпуску продуктов с дефектами защиты; • навязываемая потребителям парадигма постоянного наращивания мощности аппаратного и программного обеспечения не позволяет долго оставаться в рамках надежных, апробированных конфигураций и, кроме того, вступает в конфликт с бюджетными ограничениями, из-за чего снижается доля ассигнований на безопасность. Перечисленные соображения лишний раз подчеркивают важность комплексного подхода к информационной безопасности, а также необходимость гибкой позиции при выборе и сопровождении программно-технических регуляторов. Центральным для программно-технического уровня является понятие сервиса безопасности. Следуя объектно-ориентированному подходу, при рассмотрении информационной системы с единичным уровнем детализации мы увидим совокупность предоставляемых ею информационных сервисов. Назовем их основными . Чтобы они могли функционировать и обладали требуемыми свойствами, необходимо несколько уровней дополнительных (вспомогательных) сервисов - от СУБД и мониторов транзакций до ядра операционной системы и оборудования. К вспомогательным относятся сервисы безопасности (мы уже сталкивались с ними при рассмотрении стандартов и спецификаций в области ИБ); среди них нас в первую очередь будут интересовать универсальные, высокоуровневые, допускающие использование различными основными и вспомогательными сервисами .Далее мы рассмотрим следующие сервисы: • идентификация и аутентификация ; • управление доступом ; • протоколирование и аудит ; • шифрование ; • контроль целостности ; • экранирование ; • анализ защищенности ; • обеспечение отказоустойчивости ; • обеспечение безопасного восстановления ; • туннелирование ; • управление. Будут описаны требования к сервисам безопасности, их функциональность, возможные методы реализации и место в общей архитектуре. Если сопоставить приведенный перечень сервисов с классами функциональных требований "Общих критериев", то бросается в глаза их существенное несовпадение. Мы не будем рассматривать вопросы, связанные с приватностью, по следующей причине. На наш взгляд, сервис безопасности, хотя бы частично, должен находиться в распоряжении того, кого он защищает. В случае же с приватностью это не так: критически важные компоненты сосредоточены не на клиентской, а на серверной стороне, так что приватность по существу оказывается свойством предлагаемой информационной услуги (в простейшем случае приватность достигается путем сохранения конфиденциальности серверной регистрационной информации и защитой от перехвата данных, для чего достаточно перечисленных сервисов безопасности ). С другой стороны, наш перечень шире, чем в "Общих критериях", поскольку в него входят экранирование, анализ защищенности и туннелирование. Эти сервисы имеют важное значение сами по себе и, кроме того, могут комбинироваться с другими сервисами для получения таких необходимых защитных средств, как, например, виртуальные частные сети. Совокупность перечисленных выше сервисов безопасности мы будем называть полным набором. Считается, что его, в принципе, достаточно для построения надежной защиты на программно-техническом уровне, правда, при соблюдении целого ряда дополнительных условий (отсутствие уязвимых мест, безопасное администрирование и т.д.). Для проведения классификации сервисов безопасности и определения их места в общей архитектуре меры безопасности можно разделить на следующие виды: • превентивные, препятствующие нарушениям ИБ; • меры обнаружения нарушений ; • локализующие, сужающие зону воздействия нарушений; • меры по выявлению нарушителя ; • меры восстановления режима безопасности. Большинство сервисов безопасности попадает в число превентивных, и это, безусловно, правильно. Аудит и контроль целостности способны помочь в обнаружении нарушений ; активный аудит, кроме того, позволяет запрограммировать реакцию на нарушение с целью локализации и/или прослеживания. Направленность сервисов отказоустойчивости и безопасного восстановления очевидна. Наконец, управление играет инфраструктурную роль, обслуживая все аспекты ИС. Особенности современных информационных систем, существенные с точки зрения безопасности Информационная система типичной современной организации является весьма сложным образованием, построенным в многоуровневой архитектуре клиент/сервер, которое пользуется многочисленными внешними сервисами и, в свою очередь, предоставляет собственные сервисы вовне. Даже сравнительно небольшие магазины, обеспечивающие расчет с покупателями по пластиковым картам (и, конечно, имеющие внешний Web- сервер ), зависят от своих информационных систем и, в частности, от защищенности всех компонентов систем и коммуникаций между ними. С точки зрения безопасности наиболее существенными представляются следующие аспекты современных ИС: • корпоративная сеть имеет несколько территориально разнесенных частей (поскольку организация располагается на нескольких производственных площадках), связи между которыми находятся в ведении внешнего поставщика сетевых услуг, выходя за пределы зоны, контролируемой организацией; • корпоративная сеть имеет одно или несколько подключений к Internet ; • на каждой из производственных площадок могут находиться критически важные серверы, в доступе к которым нуждаются сотрудники, работающие на других площадках, мобильные пользователи и, возможно, сотрудники других организаций; • для доступа пользователей могут применяться не только компьютеры, но и потребительские устройства, использующие, в частности, беспроводную связь; • в течение одного сеанса работы пользователю приходится обращаться к нескольким информационным сервисам, опирающимся на разные аппаратно-программные платформы; • к доступности информационных сервисов предъявляются жесткие требования, которые обычно выражаются в необходимости круглосуточного функционирования с максимальным временем простоя порядка нескольких минут; • информационная система представляет собой сеть с активными агентами, то есть в процессе работы программные компоненты, такие как апплеты или сервлеты, передаются с одной машины на другую и выполняются в целевой среде, поддерживая связь с удаленными компонентами; • не все пользовательские системы контролируются сетевыми и/или системными администраторами организации; • программное обеспечение, особенно полученное по сети, не может считаться надежным, в нем могут быть ошибки, создающие проблемы в защите; • конфигурация информационной системы постоянно изменяется на уровнях административных данных, программ и аппаратуры (меняется состав пользователей, их привилегии и версии программ, появляются новые сервисы, новая аппаратура и т.п.). Следует учитывать еще по крайней мере два момента. Во-первых, для каждого сервиса основные грани ИБ (доступность, целостность, конфиденциальность) трактуются по-своему. Целостность с точки зрения системы управления базами данных и с точки зрения почтового сервера - вещи принципиально разные. Бессмысленно говорить о безопасности локальной или иной сети вообще, если сеть включает в себя разнородные компоненты. Следует анализировать защищенность сервисов, функционирующих в сети. Для разных сервисов и защиту строят по-разному. Во-вторых, основная угроза информационной безопасности организаций по-прежнему исходит не от внешних злоумышленников, а от собственных сотрудников. В силу изложенных причин далее будут рассматриваться распределенные, разнородные, многосервисные, эволюционирующие системы. Соответственно, нас будут интересовать решения, ориентированные на подобные конфигурации. Архитектурная безопасность Сервисы безопасности, какими бы мощными они ни были, сами по себе не могут гарантировать надежность программно-технического уровня защиты. Только проверенная архитектура способна сделать эффективным объединение сервисов, обеспечить управляемость информационной системы, ее способность развиваться и противостоять новым угрозам при сохранении таких свойств, как высокая производительность, простота и удобство использования. Теоретической основой решения проблемы архитектурной безопасности является следующее фундаментальное утверждение, которое мы уже приводили, рассматривая интерпретацию "Оранжевой книги" для сетевых конфигураций. "Пусть каждый субъект (то есть процесс, действующий от имени какого-либо пользователя) заключен внутри одного компонента и может осуществлять непосредственный доступ к объектам только в пределах этого компонента. Далее пусть каждый компонент содержит свой монитор обращений, отслеживающий все локальные попытки доступа, и все мониторы проводят в жизнь согласованную политику безопасности. Пусть, наконец, коммуникационные каналы, связывающие компоненты, сохраняют конфиденциальность и целостностьпередаваемой информации. Тогда совокупность всех мониторов образует единый монитор обращений для всей сетевой конфигурации." Обратим внимание на три принципа, содержащиеся в приведенном утверждении: • необходимость выработки и проведения в жизнь единой политики безопасности; • необходимость обеспечения конфиденциальности и целостности при сетевых взаимодействиях; • необходимость формирования составных сервисов по содержательному принципу, чтобы каждый полученный таким образом компонент обладал полным набором защитных средств и с внешней точки зрения представлял собой единое целое (не должно быть информационных потоков, идущих к незащищенным сервисам). Если какой-либо (составной) сервис не обладает полным набором защитных средств (состав полного набора описан выше), необходимо привлечение дополнительных сервисов, которые мы будем называть экранирующими. Экранирующие сервисы устанавливаются на путях доступа к недостаточно защищенным элементам; в принципе, один такой сервис может экранировать (защищать) сколь угодно большое число элементов. С практической точки зрения наиболее важными являются следующие принципы архитектурной безопасности: • непрерывность защиты в пространстве и времени, невозможность миновать защитные средства; • следование признанным стандартам, использование апробированных решений; • иерархическая организация ИС с небольшим числом сущностей на каждом уровне; • усиление самого слабого звена ; • невозможность перехода в небезопасное состояние ; • минимизация привилегий; • разделение обязанностей; • эшелонированность обороны ; • разнообразие защитных средств; • простота и управляемость информационной системы. Поясним смысл перечисленных принципов. Если у злоумышленника или недовольного пользователя появится возможность миновать защитные средства, он, разумеется, так и сделает. Определенные выше экранирующие сервисы должны исключить подобную возможность. Следование признанным стандартам и использование апробированных решений повышает надежность ИС и уменьшает вероятность попадания в тупиковую ситуацию, когда обеспечение безопасности потребует непомерно больших затрат и принципиальных модификаций. Иерархическая организация ИС с небольшим числом сущностей на каждом уровне необходима по технологическим соображениям. При нарушении данного принципа система станет неуправляемой и, следовательно, обеспечить ее безопасность будет невозможно. Надежность любой обороны определяется самым слабым звеном. Злоумышленник не будет бороться против силы, он предпочтет легкую победу над слабостью. (Часто самым слабым звеном оказывается не компьютер или программа, а человек, и тогда проблема обеспечения информационной безопасности приобретает нетехнический характер.) Принцип невозможности перехода в небезопасное состояние означает, что при любых обстоятельствах, в том числе нештатных, защитное средство либо полностью выполняет свои функции, либо полностью блокирует доступ. Образно говоря, если в крепости механизм подъемного моста ломается, мост оставляют поднятым, препятствуя проходу неприятеля. Применительно к программно-техническому уровню принцип минимизации привилегий предписывает выделять пользователям и администраторам только те права доступа, которые необходимы им для выполнения служебных обязанностей. Этот принцип позволяет уменьшить ущерб от случайных или умышленных некорректных действий пользователей и администраторов. Принцип разделения обязанностей предполагает такое распределение ролей и ответственности, чтобы один человек не мог нарушить критически важный для организации процесс или создать брешь в защите по заказу злоумышленников. В частности, соблюдение данного принципа особенно важно, чтобы предотвратить злонамеренные или неквалифицированные действия системного администратора. Принцип эшелонированности обороны предписывает не полагаться на один защитный рубеж, каким бы надежным он ни казался. За средствами физической защиты должны следовать программно-технические средства, за идентификацией и аутентификацией - управление доступом и, как последний рубеж, - протоколирование и аудит. Эшелонированная оборона способна, по крайней мере, задержать злоумышленника, а благодаря наличию такого рубежа, как протоколирование и аудит, его действия не останутся незамеченными. Принцип разнообразия защитных средств предполагает создание различных по своему характеру оборонительных рубежей, чтобы от потенциального злоумышленника требовалось овладение разнообразными и, по возможности, несовместимыми между собой навыками. Очень важен принцип простоты и управляемости информационной системы в целом и защитных средств в особенности. Только для простого защитного средства можно формально или неформально доказать его корректность. Только в простой и управляемой системе можно проверить согласованность конфигурации различных компонентов и осуществлять централизованное администрирование. В этой связи важно отметить интегрирующую роль Web-сервиса, скрывающего разнообразие обслуживаемых объектов и предоставляющего единый, наглядный интерфейс. Соответственно, если объекты некоторого вида (например, таблицы базы данных) доступны через Web, необходимо заблокировать прямойдоступ к ним, поскольку в противном случае система будет сложной и плохо управляемой. Для обеспечения высокой доступности (непрерывности функционирования) необходимо соблюдать следующие принципы архитектурной безопасности: • внесение в конфигурацию той или иной формы избыточности (резервное оборудование, запасные каналы связи и т.п.); • наличие средств обнаружения нештатных ситуаций; • наличие средств реконфигурирования для восстановления, изоляции и/или замены компонентов, отказавших или подвергшихся атаке на доступность; • рассредоточенность сетевого управления, отсутствие единой точки отказа ; • выделение подсетей и изоляция групп пользователей друг от друга. Данная мера, являющаяся обобщением разделения процессов на уровне операционной системы, ограничивает зону поражения при возможных нарушениях информационной безопасности. Еще один важный архитектурный принцип - минимизация объема защитных средств, выносимых на клиентские системы. Причин тому несколько: • для доступа в корпоративную сеть могут использоваться потребительские устройства с ограниченной функциональностью; • конфигурацию клиентских систем трудно или невозможно контролировать. К необходимому минимуму следует отнести реализацию сервисов безопасности на сетевом и транспортном уровнях и поддержку механизмов аутентификации, устойчивых к сетевым угрозам. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Перечислите и охарактеризуйте принципы архитектуры безопасности 2.Опишите аспекты современных ИС 3.Перечислите технические меры защиты информации 4. Дайте характеристику принципу распределения 5. Что означает принцип невозможности перехода в небезопасное состояние ЛЕКЦИЯ 5. ИДЕНТИФИКАЦИЯ И АУТЕНТИФИКАЦИЯ, УПРАВЛЕНИЕ ДОСТУПОМ Идентификацию и аутентификацию можно считать основой программно-технических средств безопасности, поскольку остальные сервисы рассчитаны на обслуживание именованных субъектов. Идентификация и аутентификация – это первая линия обороны, "проходная" информационного пространства организации. Идентификация позволяет субъекту (пользователю, процессу, действующему от имени определенного пользователя, или иному аппаратно-программному компоненту) назвать себя (сообщить свое имя). Посредством аутентификации вторая сторона убеждается, что субъект действительно тот, за кого он себя выдает. В качестве синонима слова " аутентификация " иногда используют словосочетание "проверка подлинности". (Заметим в скобках, что происхождение русскоязычного термина " аутентификация " не совсем понятно. Английское "authentication" скорее можно прочитать как "аутентикация"; трудно сказать, откуда в середине взялось еще "фи" – может, из идентификации? Тем не менее, термин устоялся, он закреплен в Руководящих документах Гостехкомиссии России, использован в многочисленных публикациях, поэтому исправить его уже невозможно.) Аутентификация бывает односторонней (обычно клиент доказывает свою подлинность серверу) и двусторонней ( взаимной ). Пример односторонней аутентификации – процедура входа пользователя в систему. В сетевой среде, когда стороны идентификации / аутентификации территориально разнесены, у рассматриваемого сервиса есть два основных аспекта: • что служит аутентификатором (то есть используется для подтверждения подлинности субъекта); • как организован (и защищен) обмен данными идентификации / аутентификации. Субъект может подтвердить свою подлинность, предъявив по крайней мере одну из следующих сущностей: • нечто, что он знает (пароль, личный идентификационный номер, криптографический ключ и т.п.); • нечто, чем он владеет (личную карточку или иное устройство аналогичного назначения); • нечто, что есть часть его самого (голос, отпечатки пальцев и т.п., то есть свои биометрические характеристики). В открытой сетевой среде между сторонами идентификации / аутентификации не существует доверенного маршрута; это значит, что в общем случае данные, переданные субъектом, могут не совпадать с данными, полученными и использованными для проверки подлинности. Необходимо обеспечить защиту от пассивного и активного прослушивания сети, то есть от перехвата, изменения и/или воспроизведения данных. Передача паролей в открытом виде, очевидно, неудовлетворительна; не спасает положение и шифрование паролей, так как оно не защищает от воспроизведения. Нужны более сложные протоколы аутентификации. Надежная идентификация затруднена не только из-за сетевых угроз, но и по целому ряду причин. Во-первых, почти все аутентификационные сущности можно узнать, украсть или подделать. Во-вторых, имеется противоречие между надежностью аутентификации, с одной стороны, и удобствами пользователя и системного администратора с другой. Так, из соображений безопасности необходимо с определенной частотой просить пользователя повторно вводить аутентификационную информацию (ведь на его место мог сесть другой человек), а это не только хлопотно, но и повышает вероятность того, что кто-то может подсмотреть за вводом данных. В-третьих, чем надежнее средство защиты, тем оно дороже. Современные средства идентификации / аутентификации должны поддерживать концепцию единого входа в сеть. Единый вход в сеть – это, в первую очередь, требование удобства для пользователей. Если в корпоративной сети много информационных сервисов, допускающих независимое обращение, то многократная идентификация / аутентификация становится слишком обременительной. К сожалению, пока нельзя сказать, что единый вход в сеть стал нормой, доминирующие решения пока не сформировались. Таким образом, необходимо искать компромисс между надежностью, доступностью по цене и удобством использования и администрирования средств идентификации и аутентификации. Любопытно отметить, что сервис идентификации  / аутентификации может стать объектом атак на доступность. Если система сконфигурирована так, что после определенного числа неудачных попыток устройство ввода идентификационной информации (такое, например, как терминал) блокируется, то злоумышленник может остановить работу легального пользователя буквально несколькими нажатиями клавиш. Парольная аутентификация Главное достоинство парольной аутентификации – простота и привычность. Пароли давно встроены в операционные системы и иные сервисы. При правильном использовании пароли могут обеспечить приемлемый для многих организаций уровень безопасности. Тем не менее, по совокупности характеристик их следует признать самым слабым средством проверки подлинности. Чтобы пароль был запоминающимся, его зачастую делают простым (имя подруги, название спортивной команды и т.п.). Однако простой пароль нетрудно угадать, особенно если знать пристрастия данного пользователя. Известна классическая история про советского разведчика Рихарда Зорге, объект внимания которого через слово говорил "карамба"; разумеется, этим же словом открывался сверхсекретный сейф. Иногда пароли с самого начала не хранятся в тайне, так как имеют стандартные значения, указанные в документации, и далеко не всегда после установки системы производится их смена. Ввод пароля можно подсмотреть. Иногда для подглядывания используются даже оптические приборы. Пароли нередко сообщают коллегам, чтобы те могли, например, подменить на некоторое время владельца пароля. Теоретически в подобных случаях более правильно задействовать средства управления доступом, но на практике так никто не поступает; а тайна, которую знают двое, это уже не тайна. Пароль можно угадать "методом грубой силы", используя, скажем, словарь. Если файл паролей зашифрован, но доступен для чтения, его можно скачать к себе на компьютер и попытаться подобрать пароль, запрограммировав полный перебор (предполагается, что алгоритм шифрования известен). Тем не менее, следующие меры позволяют значительно повысить надежность парольной защиты: • наложение технических ограничений (пароль должен быть не слишком коротким, он должен содержать буквы, цифры, знаки пунктуации и т.п.); • управление сроком действия паролей, их периодическая смена; • ограничение доступа к файлу паролей; • ограничение числа неудачных попыток входа в систему (это затруднит применение "метода грубой силы"); • обучение пользователей; • использование программных генераторов паролей (такая программа, основываясь на несложных правилах, может порождать только благозвучные и, следовательно, запоминающиеся пароли). • Перечисленные меры целесообразно применять всегда, даже если наряду с паролями используются другие методы аутентификации. Одноразовые пароли Рассмотренные выше пароли можно назвать многоразовыми ; их раскрытие позволяет злоумышленнику действовать от имени легального пользователя. Гораздо более сильным средством, устойчивым к пассивному прослушиванию сети, являются одноразовые пароли. Наиболее известным программным генератором одноразовых паролей является система S/KEY компании Bellcore. Идея этой системы состоит в следующем. Пусть имеется односторонняя функция f (то есть функция, вычислить обратную которой за приемлемое время не представляется возможным). Эта функция известна и пользователю, и серверу аутентификации. Пусть, далее, имеется секретный ключ K, известный только пользователю. На этапе начального администрирования пользователя функция f применяется к ключу K n раз, после чего результат сохраняется на сервере. После этого процедура проверки подлинности пользователя выглядит следующим образом: • сервер присылает на пользовательскую систему число (n-1); • пользователь применяет функцию f к секретному ключу K (n-1) раз и отправляет результат по сети на сервер аутентификации; • сервер применяет функцию f к полученному от пользователя значению и сравнивает результат с ранее сохраненной величиной. В случае совпадения подлинность пользователя считается установленной, сервер запоминает новое значение (присланное пользователем) и уменьшает на единицу счетчик (n). На самом деле реализация устроена чуть сложнее (кроме счетчика, сервер посылает затравочное значение, используемое функцией f), но для нас сейчас это не важно. Поскольку функция f необратима, перехват пароля, равно как и получение доступа к серверу аутентификации, не позволяют узнать секретный ключ K и предсказать следующий одноразовый пароль. Система S/KEY имеет статус Internet-стандарта (RFC 1938). Другой подход к надежной аутентификации состоит в генерации нового пароля через небольшой промежуток времени (например, каждые 60 секунд), для чего могут использоваться программы или специальные интеллектуальные карты (с практической точки зрения такие пароли можно считать одноразовыми). Серверу аутентификации должен быть известен алгоритм генерации паролей и ассоциированные с ним параметры; кроме того, часы клиента и сервера должны быть синхронизированы. Сервер аутентификации Kerberos Kerberos – это программный продукт, разработанный в середине 1980-х годов в Массачусетском технологическом институте и претерпевший с тех пор ряд принципиальных изменений. Клиентские компоненты Kerberos присутствуют в большинстве современных операционных систем. Kerberos предназначен для решения следующей задачи. Имеется открытая (незащищенная) сеть, в узлах которой сосредоточены субъекты – пользователи, а также клиентские и серверные программные системы. Каждый субъект обладает секретным ключом. Чтобы субъект C мог доказать свою подлинность субъекту S (без этого S не станет обслуживать C), он должен не только назвать себя, но и продемонстрировать знание секретного ключа. C не может просто послать S свой секретный ключ, во-первых, потому, что сеть открыта (доступна для пассивного и активного прослушивания), а, во-вторых, потому, что S не знает (и не должен знать) секретный ключ C. Требуется менее прямолинейный способ демонстрации знания секретного ключа. Система Kerberos представляет собой доверенную третью сторону (то есть сторону, которой доверяют все), владеющую секретными ключами обслуживаемых субъектов и помогающую им в попарной проверке подлинности. Чтобы с помощью Kerberos получить доступ к S (обычно это сервер), C (как правило – клиент) посылает Kerberos запрос, содержащий сведения о нем (клиенте) и о запрашиваемой услуге. В ответ Kerberos возвращает так называемый билет, зашифрованный секретным ключом сервера, и копию части информации из билета, зашифрованную секретным ключом клиента. Клиент должен расшифровать вторую порцию данных и переслать ее вместе с билетом серверу. Сервер, расшифровав билет, может сравнить его содержимое с дополнительной информацией, присланной клиентом. Совпадение свидетельствует о том, что клиент смог расшифровать предназначенные ему данные (ведь содержимое билета никому, кроме сервера и Kerberos, недоступно), то есть продемонстрировал знание секретного ключа. Значит, клиент – именно тот, за кого себя выдает. Подчеркнем, что секретные ключи в процессе проверки подлинности не передавались по сети (даже в зашифрованном виде) – они только использовались для шифрования. Как организован первоначальный обмен ключами между Kerberos и субъектами и как субъекты хранят свои секретные ключи – вопрос отдельный. Проиллюстрируем описанную процедуру. Рис. 5.1. Проверка сервером S подлинности клиента C. Здесь c и s – сведения (например, имя), соответственно, о клиенте и сервере, d1 и d2 – дополнительная (по отношению к билету) информация, Tc.s – билет для клиента C на обслуживание у сервера S, Kc и Ks – секретные ключи клиента и сервера, {info}K – информация info, зашифрованная ключом K. Приведенная схема – крайне упрощенная версия реальной процедуры проверки подлинности. Более подробное рассмотрение системы Kerberosможно найти, например, в статье В. Галатенко "Сервер аутентификации Kerberos (Jet Info, 1996, 12-13). Нам же важно отметить, что Kerberos не только устойчив к сетевым угрозам, но и поддерживает концепцию единого входа в сеть. Идентификация/аутентификация с помощью биометрических данных Биометрия представляет собой совокупность автоматизированных методов идентификации и/или аутентификации людей на основе их физиологических и поведенческих характеристик. К числу физиологических характеристик принадлежат особенности отпечатков пальцев, сетчатки и роговицы глаз, геометрия руки и лица и т.п. К поведенческим характеристикам относятся динамика подписи (ручной), стиль работы с клавиатурой. На стыке физиологии и поведения находятся анализ особенностей голоса и распознавание речи. Биометрией во всем мире занимаются очень давно, однако долгое время все, что было связано с ней, отличалось сложностью и дороговизной. В последнее время спрос на биометрические продукты, в первую очередь в связи с развитием электронной коммерции, постоянно и весьма интенсивно растет. Это понятно, поскольку с точки зрения пользователя гораздо удобнее предъявить себя самого, чем что-то запоминать. Спрос рождает предложение, и на рынке появились относительно недорогие аппаратно-программные продукты, ориентированные в основном на распознавание отпечатков пальцев. В общем виде работа с биометрическими данными организована следующим образом. Сначала создается и поддерживается база данных характеристик потенциальных пользователей. Для этого биометрические характеристики пользователя снимаются, обрабатываются, и результат обработки (называемый биометрическим шаблоном ) заносится в базу данных (исходные данные, такие как результат сканирования пальца или роговицы, обычно не хранятся). В дальнейшем для идентификации (и одновременно аутентификации ) пользователя процесс снятия и обработки повторяется, после чего производится поиск в базе данных шаблонов. В случае успешного поиска личность пользователя и ее подлинность считаются установленными. Для аутентификации достаточно произвести сравнение с одним биометрическим шаблоном, выбранным на основе предварительно введенных данных. Обычно биометрию применяют вместе с другими аутентификаторами, такими, например, как интеллектуальные карты. Иногда биометрическая аутентификация является лишь первым рубежом защиты и служит для активизации интеллектуальных карт, хранящих криптографические секреты; в таком случае биометрический шаблон хранится на той же карте. На наш взгляд, к биометрии следует относиться весьма осторожно. Необходимо учитывать, что она подвержена тем же угрозам, что и другие методы аутентификации. Во-первых, биометрический шаблон сравнивается не с результатом первоначальной обработки характеристик пользователя, а с тем, что пришло к месту сравнения. А, как известно, за время пути... много чего может произойти. Во-вторых, биометрические методы не более надежны, чем база данных шаблонов. В-третьих, следует учитывать разницу между применением биометрии на контролируемой территории, под бдительным оком охраны, и в "полевых" условиях, когда, например к устройству сканирования роговицы могут поднести муляж и т.п. В-четвертых, биометрические данные человека меняются, так что база шаблонов нуждается в сопровождении, что создает определенные проблемы и для пользователей, и для администраторов. Но главная опасность состоит в том, что любая "пробоина" для биометрии оказывается фатальной. Пароли, при всей их ненадежности, в крайнем случае можно сменить. Утерянную аутентификационную карту можно аннулировать и завести новую. Палец же, глаз или голос сменить нельзя. Если биометрические данные окажутся скомпрометированы, придется как минимум производить существенную модернизацию всей системы. Управление доступом Основные понятия С традиционной точки зрения средства управления доступом позволяют специфицировать и контролировать действия, которые субъекты (пользователи и процессы) могут выполнять над объектами (информацией и другими компьютерными ресурсами). В данном разделе речь идет о логическом управлении доступом, которое, в отличие от физического, реализуется программными средствами. Логическое управление доступом – это основной механизм многопользовательских систем, призванный обеспечить конфиденциальность и целостность объектов и, до некоторой степени, их доступность (путем запрещения обслуживания неавторизованных пользователей). Рассмотрим формальную постановку задачи в традиционной трактовке. Имеется совокупность субъектов и набор объектов. Задача логического управления доступом состоит в том, чтобы для каждой пары "субъект-объект" определить множество допустимых операций (зависящее, быть может, от некоторых дополнительных условий) и контролировать выполнение установленного порядка. Отношение "субъекты-объекты" можно представить в виде матрицы доступа, в строках которой перечислены субъекты, в столбцах – объекты, а в клетках, расположенных на пересечении строк и столбцов, записаны дополнительные условия (например, время и место действия) и разрешенные виды доступа. Фрагмент матрицы может выглядеть, например, так: Таблица 5.1. Фрагмент матрицы доступа Файл Программа Линия связи Реляционная таблица Пользователь 1 orw с системной консоли e rw с 8:00 до 18:00 Пользователь 2 a "o" – обозначает разрешение на передачу прав доступа другим пользователям, "r" – чтение, "w" – запись, "e" – выполнение, "a" – добавление информации Тема логического управления доступом – одна из сложнейших в области информационной безопасности. Дело в том, что само понятие объекта (а тем более видов доступа) меняется от сервиса к сервису. Для операционной системы к объектам относятся файлы, устройства и процессы. Применительно к файлам и устройствам обычно рассматриваются права на чтение, запись, выполнение (для программных файлов), иногда на удаление и добавление. Отдельным правом может быть возможность передачи полномочий доступа другим субъектам (так называемое право владения). Процессы можно создавать и уничтожать. Современные операционные системы могут поддерживать и другие объекты. Для систем управления реляционными базами данных объект – это база данных, таблица, представление, хранимая процедура. К таблицам применимы операции поиска, добавления, модификации и удаления данных, у других объектов иные виды доступа. Разнообразие объектов и применимых к ним операций приводит к принципиальной децентрализации логического управления доступом. Каждый сервис должен сам решать, позволить ли конкретному субъекту ту или иную операцию. Теоретически это согласуется с современным объектно-ориентированным подходом, на практике же приводит к значительным трудностям. Главная проблема в том, что ко многим объектам можно получить доступ с помощью разных сервисов (возможно, при этом придется преодолеть некоторые технические трудности). Так, до реляционных таблиц можно добраться не только средствами СУБД, но и путем непосредственного чтения файлов или дисковых разделов, поддерживаемых операционной системой (разобравшись предварительно в структуре хранения объектов базы данных). В результате при задании матрицы доступа нужно принимать во внимание не только принцип распределения привилегий для каждого сервиса, но и существующие связи между сервисами (приходится заботиться о согласованности разных частей матрицы). Аналогичная трудность возникает при экспорте/импорте данных, когда информация о правах доступа, как правило, теряется (поскольку на новом сервисе она не имеет смысла). Следовательно, обмен данными между различными сервисами представляет особую опасность с точки зрения управления доступом, а при проектировании и реализации разнородной конфигурации необходимо позаботиться о согласованном распределении прав доступа субъектов к объектам и о минимизации числа способов экспорта/импорта данных. При принятии решения о предоставлении доступа обычно анализируется следующая информация: • идентификатор субъекта (идентификатор пользователя, сетевой адрес компьютера и т.п.). Подобные идентификаторы являются основой произвольного (или дискреционного) управления доступом ; • атрибуты субъекта (метка безопасности, группа пользователя и т.п.). Метки безопасности – основа принудительного (мандатного) управления доступом. Матрицу доступа, ввиду ее разреженности (большинство клеток – пустые), неразумно хранить в виде двухмерного массива. Обычно ее хранят по столбцам, то есть для каждого объекта поддерживается список "допущенных" субъектов вместе с их правами. Элементами списков могут быть имена групп и шаблоны субъектов, что служит большим подспорьем администратору. Некоторые проблемы возникают только при удалении субъекта, когда приходится удалять его имя из всех списков доступа; впрочем, эта операция производится не часто. Списки доступа – исключительно гибкое средство. С их помощью легко выполнить требование о гранулярности прав с точностью до пользователя. Посредством списков несложно добавить права или явным образом запретить доступ (например, чтобы наказать нескольких членов группы пользователей). Безусловно, списки являются лучшим средством произвольного управления доступом. Подавляющее большинство операционных систем и систем управления базами данных реализуют именно произвольное управление доступом. Основное достоинство произвольного управления – гибкость. Вообще говоря, для каждой пары "субъект-объект" можно независимо задавать права доступа (особенно легко это делать, если используются списки управления доступом ). К сожалению, у "произвольного" подхода есть ряд недостатков. Рассредоточенность управления доступом ведет к тому, что доверенными должны быть многие пользователи, а не только системные операторы или администраторы. Из-за рассеянности или некомпетентности сотрудника, владеющего секретной информацией, эту информацию могут узнать и все остальные пользователи. Следовательно, произвольность управления должна быть дополнена жестким контролем за реализацией избранной политики безопасности. Второй недостаток, который представляется основным, состоит в том, что права доступа существуют отдельно от данных. Ничто не мешает пользователю, имеющему доступ к секретной информации, записать ее в доступный всем файл или заменить полезную утилиту ее "троянским" аналогом. Подобная "разделенность" прав и данных существенно осложняет проведение несколькими системами согласованной политики безопасности и, главное, делает практически невозможным эффективный контроль согласованности. Возвращаясь к вопросу представления матрицы доступа, укажем, что для этого можно использовать также функциональный способ, когда матрицу не хранят в явном виде, а каждый раз вычисляют содержимое соответствующих клеток. Например, при принудительном управлении доступом применяется сравнение меток безопасности субъекта и объекта. Удобной надстройкой над средствами логического управления доступом является ограничивающий интерфейс, когда пользователя лишают самой возможности попытаться совершить несанкционированные действия, включив в число видимых ему объектов только те, к которым он имеет доступ. Подобный подход обычно реализуют в рамках системы меню (пользователю показывают лишь допустимые варианты выбора) или посредством ограничивающих оболочек, таких как restricted shell в ОС Unix. В заключение подчеркнем важность управления доступом не только на уровне операционной системы, но и в рамках других сервисов, входящих в состав современных приложений, а также, насколько это возможно, на "стыках" между сервисами. Здесь на первый план выходит существование единой политики безопасности организации, а также квалифицированное и согласованное системное администрирование. Ролевое управление доступом При большом количестве пользователей традиционные подсистемы управления доступом становятся крайне сложными для администрирования. Число связей в них пропорционально произведению количества пользователей на количество объектов. Необходимы решения в объектно-ориентированном стиле, способные эту сложность понизить. Таким решением является ролевое управление доступом (РУД). Суть его в том, что между пользователями и их привилегиями появляются промежуточные сущности – роли. Для каждого пользователя одновременно могут быть активными несколько ролей, каждая из которых дает ему определенные права (см. рис. 5.2). Рис. 5.2. Пользователи, объекты и роли. Ролевой доступ нейтрален по отношению к конкретным видам прав и способам их проверки; его можно рассматривать как объектно-ориентированный каркас, облегчающий администрирование, поскольку он позволяет сделать подсистему разграничения доступа управляемой при сколь угодно большом числе пользователей, прежде всего за счет установления между ролями связей, аналогичных наследованию в объектно-ориентированных системах. Кроме того, ролей должно быть значительно меньше, чем пользователей. В результате число администрируемых связей становится пропорциональным сумме (а не произведению) количества пользователей и объектов, что по порядку величины уменьшить уже невозможно. Ролевой доступ развивается более 10 лет (сама идея ролей, разумеется, значительно старше) как на уровне операционных систем, так и в рамках СУБД и других информационных сервисов. В частности, существуют реализации ролевого доступа для Web-серверов. Ролевое управление доступом оперирует следующими основными понятиями: • пользователь (человек, интеллектуальный автономный агент и т.п.); • сеанс работы пользователя ; • роль (обычно определяется в соответствии с организационной структурой); • объект (сущность, доступ к которой разграничивается; например, файл ОС или таблица СУБД); • операция (зависит от объекта; для файлов ОС – чтение, запись, выполнение и т.п.; для таблиц СУБД – вставка, удаление и т.п., для прикладных объектов операции могут быть более сложными); • право доступа (разрешение выполнять определенные операции над определенными объектами). Ролям приписываются пользователи и права доступа ; можно считать, что они (роли) именуют отношения "многие ко многим" между пользователями и правами. Роли могут быть приписаны многим пользователям; один пользователь может быть приписан нескольким ролям. Во время сеанса работы пользователя активизируется подмножество ролей, которым он приписан, в результате чего он становится обладателем объединения прав, приписанных активным ролям. Одновременно пользователь может открыть несколько сеансов. Между ролями может быть определено отношение частичного порядка, называемое наследованием. Если роль r2 является наследницей r1, то все права r1 приписываются r2, а все пользователи r2 приписываются r1. Очевидно, что наследование ролей соответствует наследованию классов в объектно-ориентированном программировании, только правам доступа соответствуют методы классов, а пользователям – объекты (экземпляры) классов. Отношение наследования является иерархическим, причем права доступа и пользователи распространяются по уровням иерархии навстречу друг другу. В общем случае наследование является множественным, то есть у одной роли может быть несколько предшественниц (и, естественно, несколько наследниц, которых мы будем называть также преемницами). Можно представить себе формирование иерархии ролей, начиная с минимума прав (и максимума пользователей), приписываемых роли "сотрудник", с постепенным уточнением состава пользователей и добавлением прав (роли "системный администратор", "бухгалтер" и т.п.), вплоть до роли "руководитель" (что, впрочем, не значит, что руководителю предоставляются неограниченные права; как и другим ролям, в соответствии с принципом минимизации привилегий, этой роли целесообразно разрешить только то, что необходимо для выполнения служебных обязанностей). Фрагмент подобной иерархии ролей показан на рис. 5.3. Рис. 5.3. Фрагмент иерархии ролей. Для реализации еще одного упоминавшегося ранее важного принципа информационной безопасности вводится понятие разделения обязанностей, причем в двух видах: статическом и динамическом. Статическое разделение обязанностей налагает ограничения на приписывание пользователей ролям. В простейшем случае членство в некоторой роли запрещает приписывание пользователя определенному множеству других ролей. В общем случае данное ограничение задается как пара "множество ролей – число" (где множество состоит, по крайней мере, из двух ролей, а число должно быть больше 1), так что никакой пользователь не может быть приписан указанному (или большему) числу ролей из заданного множества. Например, может существовать пять бухгалтерских ролей, но политика безопасности допускает членство не более чем в двух таких ролях (здесь число=3). При наличии наследования ролей ограничение приобретает несколько более сложный вид, но суть остается простой: при проверке членства в ролях нужно учитывать приписывание пользователей ролям-наследницам. Динамическое разделение обязанностей отличается от статического только тем, что рассматриваются роли, одновременно активные (быть может, в разных сеансах) для данного пользователя (а не те, которым пользователь статически приписан). Например, один пользователь может играть роль и кассира, и контролера, но не одновременно; чтобы стать контролером, он должен сначала закрыть кассу. Тем самым реализуется так называемое временное ограничение доверия, являющееся аспектом минимизации привилегий. Рассматриваемый проект стандарта содержит спецификации трех категорий функций, необходимых для администрирования РУД: • Административные функции (создание и сопровождение ролей и других атрибутов ролевого доступа): создать/удалить роль/пользователя, приписать пользователя/право роли или ликвидировать существующую ассоциацию, создать/удалить отношение наследования между существующими ролями, создать новую роль и сделать ее наследницей/предшественницей существующей роли, создать/удалить ограничения для статического/динамического разделения обязанностей. • Вспомогательные функции (обслуживание сеансов работы пользователей): открыть сеанс работы пользователя с активацией подразумеваемого набора ролей; активировать новую роль, деактивировать роль; проверить правомерность доступа. • Информационные функции (получение сведений о текущей конфигурации с учетом отношения наследования). Здесь проводится разделение на обязательные и необязательные функции. К числу первых принадлежат получение списка пользователей, приписанных роли, и списка ролей, которым приписан пользователь. Все остальные функции отнесены к разряду необязательных. Это получение информации о правах, приписанных роли, о правах заданного пользователя (которыми он обладает как член множества ролей), об активных в данный момент сеанса ролях и правах, об операциях, которые роль/пользователь правомочны совершить над заданным объектом, о статическом/динамическом разделении обязанностей. Можно надеяться, что предлагаемый стандарт поможет сформировать единую терминологию и, что более важно, позволит оценивать РУД-продукты с единых позиций, по единой шкале. КОНТРОЛЬНЫЕ ВОПРОСЫ 1.Дайте характеристику матрицы доступа 2.Опишите ролевое управление доступом 3.Перечислите возможные пароли и различие их использования 4.Опишите работу сервера аутентификации Kerberos 5.Что представляет собой парольная аутентификация ЛЕКЦИЯ 6. ПРОТОКОЛИРОВАНИЕ И АУДИТ, ШИФРОВАНИЕ, КОНТРОЛЬ ЦЕЛОСТНОСТИ 1 Протоколирование и аудит. Основные понятия Под протоколированием понимается сбор и накопление информации о событиях, происходящих в информационной системе. У каждого сервиса свой набор возможных событий, но в любом случае их можно разделить на внешние (вызванные действиями других сервисов), внутренние (вызванные действиями самого сервиса) и клиентские (вызванные действиями пользователей и администраторов). Аудит – это анализ накопленной информации, проводимый оперативно, в реальном времени или периодически (например, раз в день). Оперативный аудит с автоматическим реагированием на выявленные нештатные ситуации называется активным. Реализация протоколирования и аудита решает следующие задачи: • обеспечение подотчетности пользователей и администраторов; • обеспечение возможности реконструкции последовательности событий; • обнаружение попыток нарушений информационной безопасности; • предоставление информации для выявления и анализа проблем. Протоколирование требует для своей реализации здравого смысла. Какие события регистрировать? С какой степенью детализации? На подобные вопросы невозможно дать универсальные ответы. Необходимо следить за тем, чтобы, с одной стороны, достигались перечисленные выше цели, а, с другой, расход ресурсов оставался в пределах допустимого. Слишком обширное или подробное протоколирование не только снижает производительность сервисов (что отрицательно сказывается на доступности), но и затрудняет аудит, то есть не увеличивает, а уменьшает информационную безопасность. Разумный подход к упомянутым вопросам применительно к операционным системам предлагается в "Оранжевой книге", где выделены следующие события: • вход в систему (успешный или нет); • выход из системы; • обращение к удаленной системе; • операции с файлами (открыть, закрыть, переименовать, удалить); • смена привилегий или иных атрибутов безопасности (режима доступа, уровня благонадежности пользователя и т.п.). При протоколировании события рекомендуется записывать, по крайней мере, следующую информацию: • дата и время события; • уникальный идентификатор пользователя – инициатора действия; • тип события; • результат действия (успех или неудача); • источник запроса (например, имя терминала); • имена затронутых объектов (например, открываемых или удаляемых файлов); • описание изменений, внесенных в базы данных защиты (например, новая метка безопасности объекта). Еще одно важное понятие, фигурирующее в "Оранжевой книге", – выборочное протоколирование, как в отношении пользователей (внимательно следить только за подозрительными), так и в отношении событий. Характерная особенность протоколирования и аудита – зависимость от других средств безопасности. Идентификация и аутентификация служат отправной точкой подотчетности пользователей, логическое управление доступом защищает конфиденциальность и целостность регистрационной информации. Возможно, для защиты привлекаются и криптографические методы. Возвращаясь к целям протоколирования и аудита, отметим, что обеспечение подотчетности важно в первую очередь как сдерживающее средство. Если пользователи и администраторы знают, что все их действия фиксируются, они, возможно, воздержатся от незаконных операций. Очевидно, если есть основания подозревать какого-либо пользователя в нечестности, можно регистрировать все его действия, вплоть до каждого нажатия клавиши. При этом обеспечивается не только возможность расследования случаев нарушения режима безопасности, но и откат некорректных изменений (если в протоколе присутствуют данные до и после модификации). Тем самым защищается целостность информации. Реконструкция последовательности событий позволяет выявить слабости в защите сервисов, найти виновника вторжения, оценить масштабы причиненного ущерба и вернуться к нормальной работе. Обнаружение попыток нарушений информационной безопасности – функция активного аудита, о котором пойдет речь в следующем разделе. Обычный аудит позволяет выявить подобные попытки с опозданием, но и это оказывается полезным. В свое время поимка немецких хакеров, действовавших по заказу КГБ, началась с выявления подозрительного расхождения в несколько центов в ежедневном отчете крупного вычислительного центра. Выявление и анализ проблем могут помочь улучшить такой параметр безопасности, как доступность. Обнаружив узкие места, можно попытаться переконфигурировать или перенастроить систему, снова измерить производительность и т.д. Непросто осуществить организацию согласованного протоколирования и аудита в распределенной разнородной системе. Во-первых, некоторые компоненты, важные для безопасности (например, маршрутизаторы), могут не обладать своими ресурсами протоколирования; в таком случае их нужно экранировать другими сервисами, которые возьмут протоколирование на себя. Во-вторых, необходимо увязывать между собой события в разных сервисах. 2 Активный аудит. Основные понятия Под подозрительной активностью понимается поведение пользователя или компонента информационной системы, являющееся злоумышленным (в соответствии с заранее определенной политикой безопасности) или нетипичным (согласно принятым критериям). Задача активного аудита – оперативно выявлять подозрительную активность и предоставлять средства для автоматического реагирования на нее. Активность, не соответствующую политике безопасности, целесообразно разделить на атаки, направленные на незаконное получение полномочий, и на действия, выполняемые в рамках имеющихся полномочий, но нарушающие политику безопасности. Атаки нарушают любую осмысленную политику безопасности. Иными словами, активность атакующего является разрушительной независимо от политики. Следовательно, для описания и выявления атак можно применять универсальные методы, инвариантные относительно политики безопасности, такие как сигнатуры и их обнаружение во входном потоке событий с помощью аппарата экспертных систем. Сигнатура атаки – это совокупность условий, при выполнении которых атака считается имеющей место, что вызывает заранее определенную реакцию. Простейший пример сигнатуры – "зафиксированы три последовательные неудачные попытки входа в систему с одного терминала", пример ассоциированной реакции – блокирование терминала до прояснения ситуации. Действия, выполняемые в рамках имеющихся полномочий, но нарушающие политику безопасности, мы будем называть злоупотреблением полномочиями. Злоупотребления полномочиями возможны из-за неадекватности средств разграничения доступа выбранной политике безопасности. Простейшим примером злоупотреблений является неэтичное поведение суперпользователя, просматривающего личные файлы других пользователей. Анализируя регистрационную информацию, можно обнаружить подобные события и сообщить о них администратору безопасности, хотя для этого необходимы соответствующие средства выражения политики безопасности. Выделение злоупотреблений полномочиями в отдельную группу неправомерных действий, выявляемых средствами активного аудита, не является общепринятым, однако, на наш взгляд, подобный подход имеет право на существование и мы будем его придерживаться, хотя наиболее радикальным решением было бы развитие средств разграничения доступа (см. "Возможный подход к управлению доступом в распределенной объектной среде"). Нетипичное поведение выявляется статистическими методами. В простейшем случае применяют систему порогов, превышение которых является подозрительным. (Впрочем, "пороговый" метод можно трактовать и как вырожденный случай сигнатуры атаки, и как тривиальный способ выражения политики безопасности.) В более развитых системах производится сопоставление долговременных характеристик работы (называемых долгосрочным профилем) с краткосрочными профилями. (Здесь можно усмотреть аналогию биометрической аутентификации по поведенческим характеристикам.) Применительно к средствам активного аудита различают ошибки первого и второго рода: пропуск атак и ложные тревоги, соответственно. Нежелательность ошибок первого рода очевидна; ошибки второго рода не менее неприятны, поскольку отвлекают администратора безопасности от действительно важных дел, косвенно способствуя пропуску атак. Достоинства сигнатурного метода – высокая производительность, малое число ошибок второго рода, обоснованность решений. Основной недостаток – неумение обнаруживать неизвестные атаки и вариации известных атак. Основные достоинства статистического подхода – универсальность и обоснованность решений, потенциальная способность обнаруживать неизвестные атаки, то есть минимизация числа ошибок первого рода. Минусы заключаются в относительно высокой доле ошибок второго рода, плохой работе в случае, когда неправомерное поведение является типичным, когда типичное поведение плавно меняется от легального к неправомерному, а также в случаях, когда типичного поведения нет (как показывает статистика, таких пользователей примерно 5-10%). Средства активного аудита могут располагаться на всех линиях обороны информационной системы. На границе контролируемой зоны они могут обнаруживать подозрительную активность в точках подключения к внешним сетям (не только попытки нелегального проникновения, но и действия по "прощупыванию" сервисов безопасности). В корпоративной сети, в рамках информационных сервисов и сервисов безопасности, активный аудит в состоянии обнаружить и пресечь подозрительную активность внешних и внутренних пользователей, выявить проблемы в работе сервисов, вызванные как нарушениями безопасности, так и аппаратно-программными ошибками. Важно отметить, что активный аудит, в принципе, способен обеспечить защиту от атак на доступность. К сожалению, формулировка "в принципе, способен обеспечить защиту" не случайна. Активный аудит развивается более десяти лет, и первые результаты казались весьма многообещающими. Довольно быстро удалось реализовать распознавание простых типовых атак, однако затем было выявлено множество проблем, связанных с обнаружением заранее неизвестных атак, атак распределенных, растянутых во времени и т.п. Было бы наивно ожидать полного решения подобных проблем в ближайшее время. (Оперативное пополнение базы сигнатур атак таким решением, конечно, не является.) Тем не менее, и на нынешней стадии развития активный аудит полезен как один из рубежей (вернее, как набор прослоек) эшелонированной обороны. 3 Функциональные компоненты и архитектура В составе средств активного аудита можно выделить следующие функциональные компоненты: • компоненты генерации регистрационной информации. Они находятся на стыке между средствами активного аудита и контролируемыми объектами; • компоненты хранения сгенерированной регистрационной информации; • компоненты извлечения регистрационной информации (сенсоры). Обычно различают сетевые и хостовые сенсоры, имея в виду под первыми выделенные компьютеры, сетевые карты которых установлены в режим прослушивания, а под вторыми – программы, читающие регистрационные журналы операционной системы. На наш взгляд, с развитием коммутационных технологий это различие постепенно стирается, так как сетевые сенсоры приходится устанавливать в активном сетевом оборудовании и, по сути, они становятся частью сетевой ОС; • компоненты просмотра регистрационной информации. Могут помочь при принятии решения о реагировании на подозрительную активность; • компоненты анализа информации, поступившей от сенсоров. В соответствии с данным выше определением средств активного аудита, выделяют пороговый анализатор, анализатор нарушений политики безопасности, экспертную систему, выявляющую сигнатуры атак, а также статистический анализатор, обнаруживающий нетипичное поведение; • компоненты хранения информации, участвующей в анализе. Такое хранение необходимо, например, для выявления атак, протяженных во времени; • компоненты принятия решений и реагирования ("решатели"). "Решатель" может получать информацию не только от локальных, но и от внешних анализаторов, проводя так называемый корреляционный анализ распределенных событий; • компоненты хранения информации о контролируемых объектах. Здесь могут храниться как пассивные данные, так и методы, необходимые, например, для извлечения из объекта регистрационной информации или для реагирования; • компоненты, играющие роль организующей оболочки для менеджеров активного аудита, называемые мониторами и объединяющие анализаторы, "решатели", хранилище описаний объектов и интерфейсные компоненты. В число последних входят компоненты интерфейса с другими мониторами, как равноправными, так и входящими в иерархию. Такие интерфейсы необходимы, например, для выявления распределенных, широкомасштабных атак; • компоненты интерфейса с администратором безопасности. Средства активного аудита строятся в архитектуре менеджер/агент. Основными агентскими компонентами являются сенсоры. Анализ, принятие решений – функции менеджеров. Очевидно, между менеджерами и агентами должны быть сформированы доверенные каналы. Подчеркнем важность интерфейсных компонентов. Они полезны как с внутренней для средств активного аудита точки зрения (обеспечивают расширяемость, подключение компонентов различных производителей), так и с внешней точки зрения. Между менеджерами (между компонентами анализа и "решателями") могут существовать горизонтальные связи, необходимые для анализа распределенной активности. Возможно также формирование иерархий средств активного аудита с вынесением на верхние уровни информации о наиболее масштабной и опасной активности. Обратим также внимание на архитектурную общность средств активного аудита и управления, являющуюся следствием общности выполняемых функций. Продуманные интерфейсные компоненты могут существенно облегчить совместную работу этих средств. 4 Шифрование Мы приступаем к рассмотрению криптографических сервисов безопасности, точнее, к изложению элементарных сведений, помогающих составить общее представление о компьютерной криптографии и ее месте в общей архитектуре информационных систем. Криптография необходима для реализации, по крайней мере, трех сервисов безопасности: • шифрование; • контроль целостности; • аутентификация (этот сервис был рассмотрен нами ранее). Шифрование – наиболее мощное средство обеспечения конфиденциальности. Во многих отношениях оно занимает центральное место среди программно-технических регуляторов безопасности, являясь основой реализации многих из них, и в то же время последним (а подчас и единственным) защитным рубежом. Например, для портативных компьютеров только шифрование позволяет обеспечить конфиденциальность данных даже в случае кражи. В большинстве случаев и шифрование, и контроль целостности играют глубоко инфраструктурную роль, оставаясь прозрачными и для приложений, и для пользователей. Типичное место этих сервисов безопасности – на сетевом и транспортном уровнях реализации стека сетевых протоколов. Различают два основных метода шифрования: симметричный и асимметричный. В первом из них один и тот же ключ (хранящийся в секрете) используется и для зашифрования, и для расшифрования данных. Разработаны весьма эффективные (быстрые и надежные) методы симметричного шифрования. Существует и национальный стандарт на подобные методы – ГОСТ 28147-89 "Системы обработки информации. Защита криптографическая. Алгоритм криптографического преобразования". Рис. 6.1 иллюстрирует использование симметричного шифрования. Для определенности мы будем вести речь о защите сообщений, хотя события могут развиваться не только в пространстве, но и во времени, когда зашифровываются и расшифровываются никуда не перемещающиеся файлы. Рис. 6.1. Использование симметричного метода шифрования. Основным недостатком симметричного шифрования является то, что секретный ключ должен быть известен и отправителю, и получателю. С одной стороны, это создает новую проблему распространения ключей. С другой стороны, получатель на основании наличия зашифрованного и расшифрованного сообщения не может доказать, что он получил это сообщение от конкретного отправителя, поскольку такое же сообщение он мог сгенерировать самостоятельно. В асимметричных методах используются два ключа. Один из них, несекретный (он может публиковаться вместе с другими открытыми сведениями о пользователе), применяется для шифрования, другой (секретный, известный только получателю) – для расшифрования. Самым популярным из асимметричных является метод RSA (Райвест, Шамир, Адлеман), основанный на операциях с большими (скажем, 100-значными) простыми числами и их произведениями. Проиллюстрируем использование асимметричного шифрования (см. рис. 6.2). Рис. 6.2. Использование асимметричного метода шифрования. Существенным недостатком асимметричных методов шифрования является их низкое быстродействие, поэтому данные методы приходится сочетать с симметричными (асимметричные методы на 3 – 4 порядка медленнее). Так, для решения задачи эффективного шифрования с передачей секретного ключа, использованного отправителем, сообщение сначала симметрично зашифровывают случайным ключом, затем этот ключ зашифровывают открытым асимметричным ключом получателя, после чего сообщение и ключ отправляются по сети. Рис. 6.3. Эффективное шифрование сообщения. Отметим, что асимметричные методы позволили решить важную задачу совместной выработки секретных ключей (это существенно, если стороны не доверяют друг другу), обслуживающих сеанс взаимодействия, при изначальном отсутствии общих секретов. Для этого используется алгоритм Диффи-Хелмана. Рис. 6.4. Расшифрование эффективно зашифрованного сообщения. Определенное распространение получила разновидность симметричного шифрования, основанная на использовании составных ключей. Идея состоит в том, что секретный ключ делится на две части, хранящиеся отдельно. Каждая часть сама по себе не позволяет выполнить расшифрование. Если у правоохранительных органов появляются подозрения относительно лица, использующего некоторый ключ, они могут в установленном порядке получить половинки ключа и дальше действовать обычным для симметричного расшифрования образом. Порядок работы с составными ключами – хороший пример следования принципу разделения обязанностей. Он позволяет сочетать права на разного рода тайны (персональную, коммерческую) с возможностью эффективно следить за нарушителями закона, хотя, конечно, здесь очень много тонкостей и технического, и юридического плана. Многие криптографические алгоритмы в качестве одного из параметров требуют псевдослучайное значение, в случае предсказуемости которого в алгоритме появляется уязвимость (подобное уязвимое место было обнаружено в некоторых вариантах Web-навигаторов). Генерация псевдослучайных последовательностей – важный аспект криптографии, на котором мы, однако, останавливаться не будем. Более подробную информацию о компьютерной криптографии можно почерпнуть из статьи Г. Семенова "Не только шифрование, или Обзор криптотехнологий" (Jet Info, 2001, 3). 5 Контроль целостности Криптографические методы позволяют надежно контролировать целостность как отдельных порций данных, так и их наборов (таких как поток сообщений); определять подлинность источника данных; гарантировать невозможность отказаться от совершенных действий ("неотказуемость"). В основе криптографического контроля целостности лежат два понятия: • хэш-функция; • электронная цифровая подпись (ЭЦП). Хэш-функция – это труднообратимое преобразование данных (односторонняя функция), реализуемое, как правило, средствами симметричного шифрования со связыванием блоков. Результат шифрования последнего блока (зависящий от всех предыдущих) и служит результатом хэш-функции. Пусть имеются данные, целостность которых нужно проверить, хэш-функция и ранее вычисленный результат ее применения к исходным данным (так называемый дайджест). Обозначим хэш-функцию через h, исходные данные – через T, проверяемые данные – через T'. Контроль целостности данных сводится к проверке равенства h(T') = h(T). Если оно выполнено, считается, что T' = T. Совпадение дайджестов для различных данных называется коллизией. В принципе, коллизии, конечно, возможны, поскольку мощность множества дайджестов меньше, чем мощность множества хэшируемых данных, однако то, что h есть функция односторонняя, означает, что за приемлемое время специально организовать коллизию невозможно. Рассмотрим теперь применение асимметричного шифрования для выработки и проверки электронной цифровой подписи. Пусть E(T) обозначает результат зашифрования текста T с помощью открытого ключа, а D(T) – результат расшифрования текста Т (как правило, шифрованного) с помощью секретного ключа. Чтобы асимметричный метод мог применяться для реализации ЭЦП, необходимо выполнение тождества E(D(T)) = D(E(T)) = T На рис. 11.5 показана процедура выработки электронной цифровой подписи, состоящая в шифровании преобразованием D дайджеста h(T). Рис. 6.5. Выработка электронной цифровой подписи. Проверка ЭЦП может быть реализована так, как показано на рис. 6.6. Рис. 6.6. Проверка электронной цифровой подписи. Из равенства E(S') = h(T') следует, что S' = D(h(T') (для доказательства достаточно применить к обеим частям преобразование D и вычеркнуть в левой части тождественное преобразование D(E())). Таким образом, электронная цифровая подпись защищает целостность сообщения и удостоверяет личность отправителя, то есть защищает целостность источника данных и служит основой неотказуемости. Два российских стандарта, ГОСТ Р 34.10-94 "Процедуры выработки и проверки электронной цифровой подписи на базе асимметричного криптографического алгоритма" и ГОСТ Р 34.11-94 "Функция хэширования", объединенные общим заголовком "Информационная технология. Криптографическая защита информации", регламентируют вычисление дайджеста и реализацию ЭЦП. В сентябре 2001 года был утвержден, а 1 июля 2002 года вступил в силу новый стандарт ЭЦП – ГОСТ Р 34.10-2001, разработанный специалистами ФАПСИ. Для контроля целостности последовательности сообщений (то есть для защиты от кражи, дублирования и переупорядочения сообщений) применяют временные штампы и нумерацию элементов последовательности, при этом штампы и номера включают в подписываемый текст. Цифровые сертификаты При использовании асимметричных методов шифрования (и, в частности, электронной цифровой подписи) необходимо иметь гарантию подлинности пары (имя пользователя, открытый ключ пользователя). Для решения этой задачи в спецификациях X.509 вводятся понятия цифрового сертификата и удостоверяющего центра. Удостоверяющий центр – это компонент глобальной службы каталогов, отвечающий за управление криптографическими ключами пользователей. Открытые ключи и другая информация о пользователях хранится удостоверяющими центрами в виде цифровых сертификатов, имеющих следующую структуру: • порядковый номер сертификата; • идентификатор алгоритма электронной подписи; • имя удостоверяющего центра; • срок годности; • имя владельца сертификата (имя пользователя, которому принадлежит сертификат); • открытые ключи владельца сертификата (ключей может быть несколько); • идентификаторы алгоритмов, ассоциированных с открытыми ключами владельца сертификата; • электронная подпись, сгенерированная с использованием секретного ключа удостоверяющего центра (подписывается результат хэширования всей информации, хранящейся в сертификате). Цифровые сертификаты обладают следующими свойствами: • любой пользователь, знающий открытый ключ удостоверяющего центра, может узнать открытые ключи других клиентов центра и проверить целостность сертификата; • никто, кроме удостоверяющего центра, не может модифицировать информацию о пользователе без нарушения целостности сертификата. В спецификациях X.509 не описывается конкретная процедура генерации криптографических ключей и управления ими, однако даются некоторые общие рекомендации. В частности, оговаривается, что пары ключей могут порождаться любым из следующих способов. • ключи может генерировать сам пользователь. В таком случае секретный ключ не попадает в руки третьих лиц, однако нужно решать задачу безопасной связи с удостоверяющим центром; • ключи генерирует доверенное лицо. В таком случае приходится решать задачи безопасной доставки секретного ключа владельцу и предоставления доверенных данных для создания сертификата; • ключи генерируются удостоверяющим центром. В таком случае остается только задача безопасной передачи ключей владельцу. Цифровые сертификаты в формате X.509 версии 3 стали не только формальным, но и фактическим стандартом, поддерживаемым многочисленными удостоверяющими центрами. КОНТРОЛЬНЫЕ ВОПРОСЫ 1. Опишите принцип работы протоколирования и аудита. Основные понятия назовите. 2. Охарактеризуйте активный аудит. Основные понятия перечислите 3. Перечислите функциональные компоненты и архитектура. 4. Охарактеризуйте понятие шифрование. 5. Как происходит контроль целостности. ЛЕКЦИЯ 7. ОБЩИЕ КРИТЕРИИ ОЦЕНКИ БЕЗОПАСНОСТИ ИС. ФУНКЦИОНАЛЬНЫЕ КОМПОНЕНТЫ И ТРЕБОВАНИЯ ОЦЕНКИ БЕЗОПАСНОСТИ ИС. "Общие критерии" на самом деле являются метастандартом, определяющим инструменты оценки безопасности ИС и порядок их использования. В отличие от "Оранжевой книги", ОК не содержат предопределенных "классов безопасности". Такие классы можно строить, исходя из требований безопасности, существующих для конкретной организации и/или конкретной информационной системы. С программистской точки зрения ОК можно считать набором библиотек, помогающих писать содержательные "программы" - задания по безопасности, типовые профили защиты и т.п. Программисты знают, насколько хорошая библиотека упрощает разработку программ, повышает их качество. Без библиотек, "с нуля", программы не пишут уже очень давно; оценка безопасности тоже вышла на сопоставимый уровень сложности, и "Общие критерии" предоставили соответствующий инструментарий. Важно отметить, что требования могут быть параметризованы, как и полагается библиотечным функциям. Как и "Оранжевая книга", ОК содержат два основных вида требований безопасности: • функциональные, соответствующие активному аспекту защиты, предъявляемые к функциям безопасности и реализующим их механизмам; • требования доверия, соответствующие пассивному аспекту, предъявляемые к технологии и процессу разработки и эксплуатации. Требования безопасности предъявляются, а их выполнение проверяется для определенного объекта оценки - аппаратно-программного продукта или информационной системы. Очень важно, что безопасность в ОК рассматривается не статично, а в привязке к жизненному циклу объекта оценки. Выделяются следующие этапы: • определение назначения, условий применения, целей и требований безопасности; • проектирование и разработка; • испытания, оценка и сертификация; • внедрение и эксплуатация. В ОК объект оценки рассматривается в контексте среды безопасности, которая характеризуется определенными условиями и угрозами. В свою очередь, угрозы характеризуются следующими параметрами: • источник угрозы; • метод воздействия; • уязвимые места, которые могут быть использованы; • ресурсы (активы), которые могут пострадать. Уязвимые места могут возникать из-за недостатка в: • требованиях безопасности; • проектировании ; • эксплуатации. Слабые места по возможности следует устранить, минимизировать или хотя бы постараться ограничить возможный ущерб от их преднамеренного использования или случайной активизации. С точки зрения технологии программирования в ОК использован устаревший библиотечный (не объектный) подход. Чтобы, тем не менее, структурировать пространство требований, в "Общих критериях" введена иерархия класс-семейство-компонент-элемент. Классы определяют наиболее общую, "предметную" группировку требований (например, функциональные требования подотчетности ). Семейства в пределах класса различаются по строгости и другим нюансам требований. Компонент - минимальный набор требований, фигурирующий как целое. Элемент - неделимое требование. Как и между библиотечными функциями, между компонентами ОК могут существовать зависимости. Они возникают, когда компонент сам по себе недостаточен для достижения цели безопасности. Вообще говоря, не все комбинации компонентов имеют смысл, и понятие зависимости в какой-то степени компенсирует недостаточную выразительность библиотечной организации, хотя и не заменяет объединение функций в содержательные объектные интерфейсы. Как указывалось выше, с помощью библиотек могут формироваться два вида нормативных документов: профиль защиты и задание по безопасности. Профиль защиты (ПЗ) представляет собой типовой набор требований, которым должны удовлетворять продукты и/или системы определенного класса (например, операционные системы на компьютерах в правительственных организациях). Задание по безопасности содержит совокупность требований к конкретной разработке, выполнение которых обеспечивает достижение поставленных целей безопасности. Выше мы отмечали, что в ОК нет готовых классов защиты. Сформировать классификацию в терминах "Общих критериев" - значит определить несколько иерархически упорядоченных (содержащих усиливающиеся требования) профилей защиты, в максимально возможной степени использующих стандартные функциональные требования и требования доверия безопасности. Выделение некоторого подмножества из всего множества профилей защиты во многом носит субъективный характер. По целому ряду соображений (одним из которых является желание придерживаться объектно-ориентированного подхода) целесообразно, на наш взгляд, сформировать сначала отправную точку классификации, выделив базовый (минимальный) ПЗ, а дополнительные требования компоновать в функциональные пакеты. Функциональный пакет - это неоднократно используемая совокупность компонентов, объединенных для достижения определенных целей безопасности. "Общие критерии" не регламентируют структуру пакетов, процедуры верификации, регистрации и т.п., отводя им роль технологического средства формирования ПЗ. Базовый профиль защиты должен включать требования к основным (обязательным в любом случае) возможностям. Производные профили получаются из базового путем добавления необходимых пакетов расширения, то есть подобно тому, как создаются производные классы в объектно-ориентированных языках программирования. Функциональные требования Функциональные требования сгруппированы на основе выполняемой ими роли или обслуживаемой цели безопасности. Всего в "Общих критериях" представлено 11 функциональных классов, 66 семейств, 135 компонентов. Это, конечно, значительно больше, чем число аналогичных сущностей в "Оранжевой книге". Перечислим классы функциональных требований ОК: • идентификация и аутентификация ; • защита данных пользователя ; • защита функций безопасности (требования относятся к целостности и контролю данных сервисов безопасности и реализующих их механизмов); • управление безопасностью (требования этого класса относятся к управлению атрибутами и параметрами безопасности); • аудит безопасности (выявление, регистрация, хранение, анализ данных, затрагивающих безопасность объекта оценки, реагирование на возможное нарушение безопасности); • доступ к объекту оценки ; • приватность (защита пользователя от раскрытия и несанкционированного использования его идентификационных данных); • использование ресурсов (требования к доступности информации); • криптографическая поддержка (управление ключами); • связь ( аутентификация сторон, участвующих в обмене данными); • доверенный маршрут/канал (для связи с сервисами безопасности). Опишем подробнее два класса, демонстрирующие особенности современного подхода к ИБ. Класс "Приватность" содержит 4 семейства функциональных требований. Анонимность. Позволяет выполнять действия без раскрытия идентификатора пользователя другим пользователям, субъектам и/или объектам. Анонимность может быть полной или выборочной. В последнем случае она может относиться не ко всем операциям и/или не ко всем пользователям (например, у уполномоченного пользователя может оставаться возможность выяснения идентификаторов пользователей). Псевдонимность. Напоминает анонимность, но при применении псевдонима поддерживается ссылка на идентификатор пользователя для обеспечения подотчетности или для других целей. Невозможность ассоциации. Семейство обеспечивает возможность неоднократного использования информационных сервисов, но не позволяет ассоциировать случаи использования между собой и приписать их одному лицу. Невозможность ассоциации защищает от построения профилей поведения пользователей (и, следовательно, от получения информации на основе подобных профилей). Скрытность. Требования данного семейства направлены на то, чтобы можно было использовать информационный сервис с сокрытием факта использования. Для реализации скрытности может применяться, например, широковещательное распространение информации, без указания конкретного адресата. Годятся для реализации скрытности и методы стеганографии, когда скрывается не только содержание сообщения (как в криптографии), но и сам факт его отправки. Еще один показательный (с нашей точки зрения) класс функциональных требований - "Использование ресурсов", содержащий требования доступности. Он включает три семейства. Отказоустойчивость. Требования этого семейства направлены на сохранение доступности информационных сервисов даже в случае сбоя или отказа. В ОК различаются активная и пассивная отказоустойчивость. Активный механизм содержит специальные функции, которые активизируются в случае сбоя. Пассивная отказоустойчивость подразумевает наличие избыточности с возможностью нейтрализации ошибок. Обслуживание по приоритетам. Выполнение этих требований позволяет управлять использованием ресурсов так, что низкоприоритетные операции не могут помешать высокоприоритетным. Распределение ресурсов. Требования направлены на защиту (путем применения механизма квот) от несанкционированной монополизации ресурсов. Мы видим, что "Общие критерии" - очень продуманный и полный документ с точки зрения функциональных требований. В то же время, хотелось бы обратить внимание и на некоторые недостатки. Первый мы уже отмечали - это отсутствие объектного подхода. Функциональные требования не сгруппированы в осмысленные наборы (объектные интерфейсы), к которым могло бы применяться наследование. Подобное положение, как известно из технологии программирования, чревато появлением слишком большого числа комбинаций функциональных компонентов, несопоставимых между собой. В современном программировании ключевым является вопрос накопления и многократного использования знаний. Стандарты - одна из форм накопления знаний. Следование в ОК "библиотечному", а не объектному подходу сужает круг фиксируемых знаний, усложняет их корректное использование. К сожалению, в "Общих критериях" отсутствуют архитектурные требования, что является естественным следствием избранного старомодного программистского подхода "снизу вверх". На наш взгляд, это серьезное упущение. Технологичность средств безопасности, следование общепризнанным рекомендациям по протоколам и программным интерфейсам, а также апробированным архитектурным решениям, таким как менеджер/агент, - необходимые качества изделий информационных технологий, предназначенных для поддержки критически важных функций, к числу которых, безусловно, относятся функции безопасности. Без рассмотрения интерфейсных аспектов системы оказываются нерасширяемыми и изолированными. Очевидно, с практической точки зрения это недопустимо. В то же время, обеспечение безопасности интерфейсов - важная задача, которую желательно решать единообразно. Требования доверия безопасности Установление доверия безопасности, согласно "Общим критериям", основывается на активном исследовании объекта оценки. Форма представления требований доверия, в принципе, та же, что и для функциональных требований. Специфика состоит в том, что каждый элемент требований доверия принадлежит одному из трех типов: • действия разработчиков ; • представление и содержание свидетельств ; • действия оценщиков. Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы: • разработка (требования для поэтапной детализации функций безопасности от краткой спецификации до реализации ); • поддержка жизненного цикла (требования к модели жизненного цикла, включая порядок устранения недостатков и защиту среды разработки); • тестирование ; • оценка уязвимостей (включая оценку стойкости функций безопасности); • поставка и эксплуатация ; • управление конфигурацией; • руководства (требования к эксплуатационной документации); • поддержка доверия (для поддержки этапов жизненного цикла после сертификации); • оценка профиля защиты; • оценка задания по безопасности. Применительно к требованиям доверия в "Общих критериях" сделана весьма полезная вещь, не реализованная, к сожалению, для функциональных требований. А именно, введены так называемые оценочные уровни доверия (их семь), содержащие осмысленные комбинации компонентов. Оценочный уровень доверия 1 (начальный) предусматривает анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации, а также независимое тестирование. Уровень применим, когда угрозы не рассматриваются как серьезные. Оценочный уровень доверия 2, в дополнение к первому уровню, предусматривает наличие проекта верхнего уровня объекта оценки, выборочное независимое тестирование, анализ стойкости функций безопасности, поиск разработчиком явных уязвимых мест. На третьем уровне ведется контроль среды разработки и управление конфигурацией объекта оценки. На уровне 4 добавляются полная спецификация интерфейсов, проекты нижнего уровня, анализ подмножества реализации, применение неформальной модели политики безопасности, независимый анализ уязвимых мест, автоматизация управления конфигурацией. Вероятно, это самый высокий уровень, которого можно достичь при существующей технологии программирования и приемлемых затратах. Уровень 5, в дополнение к предыдущим, предусматривает применение формальной модели политики безопасности, полуформальных функциональной спецификации и проекта верхнего уровня с демонстрацией соответствия между ними. Необходимо проведение анализа скрытых каналов разработчиками и оценщиками. На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня. Оценочный уровень 7 (самый высокий) предусматривает формальную верификацию проекта объекта оценки. Он применим к ситуациям чрезвычайно высокого риска. КОНТРОЛЬНЫЕ ВОПРОСЫ: 1. Опишите подробнее два класса, демонстрирующие особенности современного подхода к ИБ. 2.Перечислите два основных вида требований безопасности: 3.Перечислите требования доверия безопасности 4.Перечислите и охарактеризуйте иерархию класс-семейство-компонент-элемент. 5.Охарактеризйте функциональный пакет ЛЕКЦИЯ 8. ТРЕБОВАНИЯ ДОВЕРИЯ К БЕЗОПАСНОСТИ. СРЕДА БЕЗОПАСНОСТИ ИС. Среда безопасности – это контекст предполагаемого применения ОО. Среда безопасности включает а)    физическую среду, которая описывает все детали эксплуатации ОО, касающиеся его безопасности, включая физическую защиту, опыт и знания персонала и т.д.; б)    активы, которые требуют защиты элементами ОО; включая непосредственно информацию, типа файлов и баз данных, а также информацию, которая косвенно подчинена требованиям безопасности, типа данных авторизации и собственно реализации ИТ; в)    предназначение ОО, включая тип продукта и предполагаемую сферу его применения. Для анализа среды безопасности (среды эксплуатации продукта ИТ) рассматриваются следующие аспекты, относящиеся к безопасности ОО: —      предположения, которым должна удовлетворять среда безопасности ОО для того, чтобы он считался безопасным. Причем при оценке ОО предположения о среде безопасности принимаются без доказательств. —      угрозы безопасности активов, относящиеся к ОО. Угрозы описываются через анализ нарушителя, предполагаемого метода нападения, любых уязвимостей, которые являются предпосылкой для нападения, и идентификации активов, которые являются целью нападения. Для каждой идентифицированной угрозы оценивается риск через вероятность реализации угрозы, вероятности успешного проведения такого нападения и последствий любого возможного ущерба. —      изложение политики безопасности организации с описанием политики и правил, относящихся к ОО. Для продуктов ИТ общего предназначения или класса продуктов о политике безопасности организации могут быть сделаны, при необходимости, только рабочие предположения. Исходя из результатов анализа рисков, предположений о среде безопасности и политики безопасности организации, относящейся к ОО, устанавливаются задачи безопасности. Установление доверия безопасности, согласно "Общим критериям", основывается на активном исследовании объекта оценки. Форма представления требований доверия, в принципе, та же, что и для функциональных требований. Специфика состоит в том, что каждый элемент требований доверия принадлежит одному из трех типов: · действия разработчиков ; · представление и содержание свидетельств ; · действия оценщиков. Всего в ОК 10 классов, 44 семейства, 93 компонента требований доверия безопасности. Перечислим классы: · разработка (требования для поэтапной детализации функций безопасности от краткой спецификации до реализации ); · поддержка жизненного цикла (требования к модели жизненного цикла, включая порядок устранения недостаткови защиту среды разработки); · тестирование ; · оценка уязвимостей (включая оценку стойкости функций безопасности); · поставка и эксплуатация ; · управление конфигурацией; · руководства (требования к эксплуатационной документации); · поддержка доверия (для поддержки этапов жизненного цикла после сертификации); · оценка профиля защиты; · оценка задания по безопасности. Применительно к требованиям доверия в "Общих критериях" сделана весьма полезная вещь, не реализованная, к сожалению, для функциональных требований. А именно, введены так называемые оценочные уровни доверия (их семь), содержащие осмысленные комбинации компонентов. Оценочный уровень доверия 1 (начальный) предусматривает анализ функциональной спецификации, спецификации интерфейсов, эксплуатационной документации, а также независимое тестирование. Уровень применим, когда угрозы не рассматриваются как серьезные. Оценочный уровень доверия 2, в дополнение к первому уровню, предусматривает наличие проекта верхнего уровня объекта оценки, выборочное независимое тестирование, анализ стойкости функций безопасности, поиск разработчиком явных уязвимых мест. На третьем уровне ведется контроль среды разработки и управление конфигурацией объекта оценки. На уровне 4 добавляются полная спецификация интерфейсов, проекты нижнего уровня, анализ подмножества реализации, применение неформальной модели политики безопасности, независимый анализ уязвимых мест, автоматизация управления конфигурацией. Вероятно, это самый высокий уровень, которого можно достичь при существующей технологии программирования и приемлемых затратах. Уровень 5, в дополнение к предыдущим, предусматривает применение формальной модели политики безопасности, полуформальныхфункциональной спецификации и проекта верхнего уровня с демонстрацией соответствиямежду ними. Необходимо проведение анализа скрытых каналов разработчиками и оценщиками. На уровне 6 реализация должна быть представлена в структурированном виде. Анализ соответствия распространяется на проект нижнего уровня. Оценочный уровень 7 (самый высокий) предусматривает формальную верификацию проекта объекта оценки. Он применим к ситуациям чрезвычайно высокого риска.   Управление рисками Основные понятия Под термином «управление риском» понимается совокупность действий, направленных на снижение уровня технологического риска, уменьшение потенциальных потерь и других негативных последствий нежелательных событий. По сути дела, речь идет о предотвращении возникновения происшествий в ходе производственной деятельности и мерах по локализации негативных последствий в тех случаях, когда нежелательные события произошли. Особенностью такой стратегии обеспечения безопасности является комплексность предпринимаемых действий, включающая в себя различные аспекты - технические, организационно-управленческие, социально-экономические, медицинские, биологические и др. Основные понятия управления рисками Риск проекта - это кумулятивный эффект вероятностей наступления неопределенных событий, способных оказать отрицательное или положительное влияние на цели проекта [23]. Риски подразделяются на известные и неизвестные. Известные риски идентифицируются и подлежат управлению - создаются планы реагирования на риски и резервы на возможные потери. Неизвестные риски нельзя определить, и следовательно, невозможно спланировать действия по реагированию на такой риск. Событие риска - потенциально возможное событие, которое может нанести ущерб или принести выгоды проекту . Вероятность возникновения риска - вероятность того, что событие риска наступит [23]. Все риски имеют вероятность больше нуля и меньше 100%. Риск с вероятностью 0 не может произойти и не считается риском. Риск с вероятностью 100% также не является риском, поскольку это достоверное событие, которое должно быть предусмотрено планом проекта. Последствия риска, если он случится, выражаются через дни расписания, трудозатраты, деньги и определяют степень воздействия на цели проекта. Величина риска - показатель, объединяющий вероятность возникновения риска и его последствия. Величина рискарассчитывается путем умножения вероятности возникновения риска на соответствующие последствия. Резерв для непредвиденных обстоятельств (или резерв для покрытия неопределенности) - сумма денег или промежуток времени, которые необходимы сверх расчетных величин для снижения риска перерасхода, связанного с достижением целей проекта, до приемлемого для организации уровня; обычно включаются в базовый план стоимости или расписания проекта. Управленческий резерв - сумма денег или промежуток времени, не включаемые в базовый план стоимости или расписания проекта и используемый руководством для предотвращения негативных последствий ситуаций, которые невозможно спрогнозировать. Планирование реагирования на риски включает разработку плана управления рисками - документа, разрабатываемого в начале проекта и представляющего собой график работы с рисками в течение всего ЖЦ проекта. План содержит следующую информацию [18]. Методология - определяет и описывает подходы, инструменты и источники данных, используемые для работы с рисками. Роли и обязанности - раздел содержит описание, кто какую работу выполняет в ходе управления рисками проекта. Бюджетирование - определяет бюджет для управления рисками проекта. Временные рамки - устанавливают частоту процессов управления рисками. Инструменты - раздел определяет, какие методы количественного и качественного анализа рисков рекомендуется применять и в каких случаях. Контроль - раздел, определяющий формат плана реагирования на риски. Отчетность - определяет способы документирования результатов действий по управлению рисками и сохранение информации в базе знаний для накопления опыта и извлечения уроков. Примером методологии является дисциплина управления рисками MSF (Microsoft Solutions Framework) MSFописывает процесс непрерывного выявления и оценки рисков, их приоритизации и реализации стратегий попревентивному управлению рисками на протяжении всех фаз жизненного цикла проекта. Этапы, предшествующие анализу угроз, можно считать подготовительными, поскольку, строго говоря, они напрямую с рисками не связаны. Риск появляется там, где есть угрозы. Краткий перечень наиболее распространенных угроз был рассмотрен нами ранее. К сожалению, на практике угроз гораздо больше, причем далеко не все из них носят компьютерный характер. Так, вполне реальной угрозой является наличие мышей и тараканов в занимаемых организацией помещениях. Первые могут повредить кабели, вторые вызвать короткое замыкание. Как правило, наличие той или иной угрозы является следствием пробелов в защите информационной системы, которые, в свою очередь, объясняются отсутствием некоторых сервисов безопасности или недостатками в реализующих их защитных механизмах. Опасность прогрызания кабелей возникает не просто там, где есть мыши, она связана с отсутствием или недостаточной прочностью защитной оболочки. Первый шаг в анализе угроз - их идентификация. Рассматриваемые виды угроз следует выбирать исходя из соображений здравого смысла (исключив, например, землетрясения, однако не забывая о возможности захвата организации террористами), но в пределах выбранных видов провести максимально подробный анализ. Целесообразно выявлять не только сами угрозы, но и источникиих возникновения - это поможет в выборе дополнительных средств защиты. Например, нелегальный вход в систему может стать следствием воспроизведения начального диалога, подбора пароля или подключения к сети неавторизованного оборудования. Очевидно, для противодействия каждому из перечисленных способов нелегального входа нужны свои механизмы безопасности. После идентификации угрозы необходимо оценить вероятность ее осуществления. Допустимо использовать при этом трехбалльную шкалу (низкая (1), средняя (2) и высокая (3) вероятность). Кроме вероятности осуществления, важен размер потенциального ущерба. Например, пожары бывают нечасто, но ущерб от каждого из них, как правило, велик. Тяжесть ущерба также можно оценить по трехбалльной шкале. Оценивая размер ущерба, необходимо иметь в виду не только непосредственные расходы на замену оборудования или восстановление информации, но и более отдаленные, такие как подрыв репутации, ослабление позиций на рынке и т.п. Пусть, например, в результате дефектов в управлении доступом к бухгалтерской информации сотрудники получили возможность корректировать данные о собственной заработной плате. Следствием такого состояния дел может стать не только перерасход бюджетных или корпоративных средств, но и полное разложение коллектива, грозящее развалом организации. Уязвимые места обладают свойством притягивать к себе не только злоумышленников, но и сравнительно честных людей. Не всякий устоит перед искушением немного увеличить свою зарплату, если есть уверенность, что это сойдет с рук. Поэтому, оценивая вероятность осуществления угроз, целесообразно исходить не только из среднестатистических данных, но учитывать также специфику конкретных информационных систем. Если в подвале дома, занимаемого организацией, располагается сауна, а сам дом имеет деревянные перекрытия, то вероятность пожара, к сожалению, оказывается существенно выше средней. После того, как накоплены исходные данные и оценена степень неопределенности, можно переходить к обработке информации, то есть собственно к оценке рисков. Вполне допустимо применить такой простой метод, как умножение вероятности осуществления угрозы на предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к низкому риску, третий и четвертый - к среднему, два последних - к высокому, после чего появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина совпала с приемлемой, целесообразно рассматривать более тщательно из-за приближенного характера результата. Если какие-либо риски оказались недопустимо высокими, необходимо их нейтрализовать, реализовав дополнительные меры защиты. Как правило, для ликвидации или нейтрализации уязвимого места, сделавшего угрозу реальной, существует несколько механизмов безопасности, различных по эффективности и стоимости. Например, если велика вероятность нелегального входа в систему, можно потребовать, чтобы пользователи выбирали длинные пароли (скажем, не менее восьми символов), задействовать программу генерации паролей или закупить интегрированную систему аутентификации на основе интеллектуальных карт. Если есть вероятность умышленного повреждения сервера баз данных, что может иметь серьезные последствия, можно врезать замок в дверь серверной комнаты или поставить около каждого сервера по охраннику. Оценивая стоимость мер защиты, приходится, разумеется, учитывать не только прямые расходы на закупку оборудования и/или программ, но и расходы на внедрение новинки и, в частности, обучение и переподготовку персонала. Эту стоимость также можно оценить по трехбалльной шкале и затем сопоставить ее с разностью между вычисленным и допустимым риском. Если по этому показателю новое средство оказывается экономически выгодным, его можно взять на заметку (подходящих средств, вероятно, будет несколько). Однако если средство окажется дорогим, его не следует сразу отбрасывать, памятуя о приближенности расчетов. Выбирая подходящий способ защиты, целесообразно учитывать возможность экранирования одним механизмом обеспечения безопасности сразу нескольких прикладных сервисов. Так поступили в Массачусетском технологическом институте, защитив несколько тысяч компьютеров сервером аутентификации Kerberos. Важным обстоятельством является совместимость нового средства со сложившейся организационной и аппаратно-программной структурой, с традициями организации. Меры безопасности, как правило, носят недружественный характер, что может отрицательно сказаться на энтузиазме сотрудников. Порой сохранение духа открытости важнее минимизации материальных потерь. Впрочем, такого рода ориентиры должны быть расставлены в политике безопасности верхнего уровня. Можно представить себе ситуацию, когда для нейтрализации риска не существует эффективных и приемлемых по цене мер. Например, компания, базирующаяся в сейсмически опасной зоне, не всегда может позволить себе строительство защищенной штаб-квартиры. В таком случае приходится поднимать планку приемлемого риска и переносить центр тяжести на смягчение последствий и выработку планов восстановления после аварий, стихийных бедствий и иных происшествий. Продолжая пример с сейсмоопасностью, можно рекомендовать регулярное тиражирование данных в другой город и овладение средствами восстановления первичной базы данных. Как и всякую иную деятельность, реализацию и проверку новых регуляторов безопасности следует предварительно планировать. В плане необходимо учесть наличие финансовых средств и сроки обучения персонала. Если речь идет о программно-техническом механизме защиты, нужно составить план тестирования (автономного и комплексного). Когда намеченные меры приняты, необходимо проверить их действенность, то есть убедиться, что остаточные риски стали приемлемыми. Если это на самом деле так, значит, можно спокойно намечать дату ближайшей переоценки. В противном случае придется проанализировать допущенные ошибки и провести повторный сеанс управления рисками немедленно. 1. ЛЕКЦИЯ 9. ВИДЫ ОЦЕНОК ИС. ОЦЕНКА ЗАЩИЩЕННОСТИ ИС. В условиях использования ИТ под безопасностью понимается состояние защищенности ИС от внутренних и внешних угроз. Показатель защищенности ИС — характеристика средств системы, влияющая на защищенность и описываемая определенной группой требований, варьируемых по уровню и глубине в зависимости от класса защищенности. Для оценки реального состояния безопасности ИС могут применяться различные критерии. Анализ отечественного и зарубежного опыта показал общность подхода к определению состояния безопасности ИС в разных странах. Для предоставления пользователю возможности оценки вводится некоторая система показателей и задается иерархия классов безопасности. Каждому классу соответствует определенная совокупность обязательных функций. Степень реализации выбранных критериев показывает текущее состояние безопасности. Последующие действия сводятся к сравнению реальных угроз с реальным состоянием безопасности. Если реальное состояние перекрывает угрозы в полной мере, система безопасности считается надежной и не требует дополнительных мер. Такую систему можно отнести к классу систем с полным перекрытием угроз и каналов утечки информации. В противном случае система безопасности нуждается в дополнительных мерах защиты. Рассмотрим кратко подходы к оценке безопасности ИС в США и в России. Вопросами стандартизации и разработки нормативных требований на защиту информации, в США занимается Национальный центр компьютерной безопасности министерства обороны США (NCSC - - National Computer Security Center). Центр еще в 1983 г. издал критерии оценки безопасности компьютерных систем (TCSEC — Trusted Computer System Evaluation Criteria). Этот документ обычно называется Оранжевой книгой. В 1985 г. она была утверждена в качестве правительственного стандарта. Оранжевая книга содержит основные требования и специфирует классы для оценки уровня безопасности компьютерных систем. Используя эти критерии, NCSC тестирует эффективность механизмов контроля безопасности компьютерных систем. Критерии, перечисленные в Оранжевой книге, делают безопасность величиной, допускающей ее измерение, и позволяют оценить уровень безопасности той или иной системы. Воз- можности анализа степени безопасности ИС привели к международному признанию федерального стандарта США. NCSC считает безопасной систему, которая посредством специальных механизмов защиты контролирует доступ информации таким образом, что только имеющие соответствующие полномочия лица или процессы, выполняющиеся от их имени, могут получить доступ на чтение, запись, создание или удаление информации. В Оранжевой книге приводятся следующие уровни безопасности систем: · высший класс, обозначается как А; · промежуточный класс — В; · низкий уровень безопасности — С; · класс систем, не прошедших испытания — Д. Класс Д присваивается тем системам, которые не прошли испытания на более высокий уровень защищенности, а также системам, использующим для защиты лишь отдельные мероприятия или функции (подсистемы безопасности). Класс С разбивается на два подкласса (по возрастающей требований к защите). Так как С1 должен обеспечивать избирательную защиту, средства безопасности систем класса С1 должны удовлетворять требованиям избирательного управления доступом, обеспечивая разделение пользователей и данных. Для каждого объекта и субъекта задается перечень допустимых типов доступа (чтение, запись, печать и т.д.) субъекта к объекту. В системах этого класса обязательны идентификация (присвоение каждому субъекту персонального идентификатора) и аутентификация (установление подлинности) субъекта доступа, а также поддержка со стороны оборудования. Класс С2 должен обеспечивать управляемый доступ, а также ряд дополнительных требований. В частности, в системах этого класса обязательно ведение системного журнала, в котором должны отмечаться события, связанные с безопасностью системы. Сам журнал должен быть защищен от доступа любых пользователей, за исключением сотрудников безопасности. В системах класса В, содержащего три подкласса, должен быть полностью контролируемый доступ. Должен выполняться ряд требований, главным из которых является наличие хорошо разработанной и документированной формальной модели политики безопасности, требующей действия избирательного и полномочного управления доступом ко всем объектам системы. Вводится требование управления информационными потоками в соответствии с политикой безопасности. Политика безопасности - представляет собой набор законов, правил и практического опыта, на основе которых строятся управление, защита и распределение конфиденциальной информации. Анализ классов безопасности показывает, что, чем он выше, тем более жесткие требования предъявляются к системе. Разработаны также основные требования к проектной документации. В части стандартизации аппаратных средств ИС и телекоммуникационных сетей в США разработаны правила стандарта TEMPEST (Transient Electromagnetic Pulse Emanations Standard). Этот стандарт предусматривает применение специальных мер защиты аппаратуры от паразитных излучений электромагнитной энергии, перехват которой может привести к овладению охраняемыми сведениями. Стандарт TEMPEST обеспечивает радиус контролируемой зоны перехвата порядка одного метра. Это достигается специальными системотехническими, конструктивными и программно-аппаратными решениями. Руководящие документы (в некоторой степени аналогичные разработанным NCSC) в области защиты информации разработаны Государственной технической комиссией при Президенте Российской Федерации. Требования этих документов обязательны для исполнения только в государственном секторе либо коммерческими организациями, которые обрабатывают информацию, содержащую государственную тайну. Для остальных коммерческих структур документы носят рекомендательный характер. В одном из документов, носящем название «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем и требования по защите информации», приведена классификация автоматизированных систем на классы по условиям их функционирования в целях разработки и применения обоснованных мер по достижению требуемого уровня безопасности. Устанавливаются девять классов защищенности, каждый из которых характеризуется определенной минимальной совокупностью требований по защите. Защитные мероприятия охватывают подсистемы: · управления доступом; · регистрации и учета (ведение журналов и статистики); · криптографическую (использования различных механизмов шифрования); · обеспечения целостности; · законодательных мер; · физических мер. Достаточно важно использование документа «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности». В нем определены семь классов защищенности СВТ от несанкционированного доступа к информации. Самый низкий класс седьмой, самый высокий — первый. Каждый класс наследует требования защищенности от предыдущего. Методики оценки безопасности ИС как в США, так и в России позволяют оценить реальную безопасность информационной системы с отнесением ее к определенному классу защищенности. Класс защищенности ИС - определенная совокупность требований по защите средств ИС от несанкционированного доступа к информации. ЛЕКЦИЯ 10. ВВЕДЕНИЕ В ТЕОРИЮ НЕЧЕТКИХ МНОЖЕСТВ. ПРИКЛАДНЫЕ НЕЧЕТКИЕ СИСТЕМЫ. Понятие нечетких множеств (fuzzy sets) было введено в 1965 г. Л.Заде как обощение понятия классических множеств. В нечетком множестве каждый его элемент может принадлежать множеству частично, тогда как в классических множествах элемент или целиком принадлежит множеству, или нет. Степень принадлежности элемента a нечеткому множеству A характеризуется коэффициентом принадлежности, обозначаемому muA(a). muA(a) — действительное число, принимающее значение в диапазоне (0,1), при этом 1 означает 100%-ю (безусловную) принадлежность a к множеству А, а 0 — безусловное отсутствие a в А. Отображение множества элементов x во множество значений muA(x) образует функцию принадлежности muA(x). Функция muA(x) может быть определена явно в виде, например, алгебраического выражения или таблично (дискретно) в виде массива пар {x1/muA(x1), x2/muA(x2),...,xN/muA(xN)}. В теории нечетких множеств помимо числовых переменных существуют переменные лингвистические. Например, лингвистичекая переменная «температура тела человека» может принимать значения: «пониженная», «нормальная», «повышенная», «высокая». Нечеткое множество «нормальная температура тела» может быть дискретно задано следующим образом: {36,2/0,15, 36,3/0,33, 36,4/0,6, 36,5/0,85, 36,6/1,0, 36,7/0,85, 36,8/0,6, 36,9/0,33, 37,0/0,15}. То же множество может быть представлено следующим выражением: muнорм=exp(-((t-36.6)/0.3)2). На представленном ниже рисунке даны графики функций принадлежности для множеств, связанных с лингвистической переменной «температура тела человека». Носителем нечеткого множества A Supp(A) являются все элементы, для которых коэффициент принадлежности больше нуля, т.е. Supp(A)={x|muA(x)>0}. В приведенном выше примере табличного задания функции принадлежности носителем нечеткого множества «нормальная температура» является следующее множество: {36,2, 36,3, 36,4, 36,5, 36,6, 36,7, 36,8, 36,9, 37,0}. Два нечетких множества A и B равны между собой тогда и только тогда, когда muA(x)=muB(x) для всех элементов этих множеств. Кардинальное число нечеткого множества A — сумма коэффициентов принадлежности всех элементов этого множества, т.е. M(A)=sum[i](muA(xi)). Нечеткое множество называется нормальным, если хотя бы один его элемент имеет коэффициент принадлежности равный 1. Сечением Aalpha нечеткого множества A называется подмножество элементов A, для которых muA(x)>alpha (слабое сечение) или muA(x)>=alpha (сильное сечение), при этом alpha принадлежит [0,1]. Нечёткая логика(англ. fuzzy logic) и теория нечётких множеств — раздел математики, являющийся обобщением классической логики и теории множеств. Понятие нечёткой логики было впервые введено профессором Лотфи Заде в 1965 году. В его статье понятие множества было расширено допущением, что функция принадлежности элемента к множеству может принимать любые значения в интервале [0...1], а не только 0 или 1. Такие множества были названы нечёткими. Также автором были предложены различные логические операции над нечёткими множествами и предложено понятие лингвистической переменной, в качестве значений которой выступают нечёткие множества. Предметом нечёткой логики является построение моделей приближенных рассуждений человека и использование их в компьютерных системах Направления исследований нечёткой логики В настоящее время существует по крайней мере два основных направления научных исследований в области нечёткой логики: нечёткая логика в широком смысле (теория приближенных вычислений); нечёткая логика в узком смысле (символическая нечёткая логика). Математические основы Символическая нечёткая логика Символическая нечёткая логика основывается на понятии t-нормы. После выбора некоторой t-нормы (а её можно ввести несколькими разными способами) появляется возможность определить основные операции над пропозициональными переменными: конъюнкцию, дизъюнкцию, импликацию, отрицание и другие. Нетрудно доказать теорему о том, что дистрибутивность, присутствующая в классической логике, выполняется только в случае, когда в качестве t-нормы выбирается t-норма Гёделя. Кроме того, в силу определенных причин, в качестве импликации чаще всего выбирают операцию, называемую residium (она, вообще говоря, также зависит от выбора t-нормы). Определение основных операций, перечисленных выше, приводит к формальному определению базисной нечёткой логики, которая имеет много общего с классической булевозначной логикой (точнее, с исчислением высказываний). Существуют три основных базисных нечётких логики: логика Лукасевича, логика Гёделя и вероятностная логика (англ. product logic). Интересно, что объединение любых двух из трёх перечисленных выше логик приводит к классической булевозначной логике. Теория приближенных вычислений Основное понятие нечёткой логики в широком смысле — нечёткое множество, определяемое при помощи обобщенного понятия характеристической функции. Затем вводятся понятия объединения, пересечения и дополнения множеств (через характеристическую функцию; задать можно различными способами), понятие нечёткого отношения, а также одно из важнейших понятий — понятие лингвистической переменной. Вообще говоря, даже такой минимальный набор определений позволяет использовать нечёткую логику в некоторых приложениях, для большинства же необходимо задать ещё и правило вывода (и оператор импликации). Нечеткая логика и нейронные сети Поскольку нечеткие множества описываются функциями принадлежности, а t-нормы и k-нормы обычными математическими операциями, можно представить нечеткие логические рассуждения в виде нейронной сети. Для этого функции принадлежности надо интерпретировать как функции активации нейронов, передачу сигналов как связи, а логические t-нормы и k-нормы, как специальные виды нейронов, выполняющие математические соответствующие операции. Существует большое разнообразие подобных нейро-нечетких сетей neuro-fuzzy network (англ.). Например, ANFIS (Adaptive Neuro fuzzy Inference System) — адаптивная нейро-нечеткая система вывода.[2] (англ.) Она может быть описана в универсальной форме аппроксиматоров как кроме того, этой формулой могут быть описаны также некоторые виды нейронных сетей, такие как радиально базисные сети (RBF), многослойные персептроны (MLP), а также вейвлеты и сплайны. Под множеством понимается любое объединение некоторых различных между собой объектов (элементов - угроз, уязвимостей, ресурсов), которые при решении соответствующей задачи должны (или могут) рассматриваться как единое целое. В теории множеств разработаны средства описания элементов множества, отношений между элементами и различных операций над элементами. Теория множеств уже стала классической, по ней имеются учебники и пособия различного уровня, поэтому излагать здесь ее основы нет необходимости. Средства классической теории множеств могут найти эффективное применение при моделировании систем защиты информации. Однако в этой теории рассматриваются лишь детерминированные множества, по крайней мере, в плане принадлежности множеству заявленных его элементов. Иными словами, предполагается, что каждый элемент, указанный в перечне или в условиях формирования элементов, несомненно, принадлежит множеству, в то время как в системах защиты информации большую роль играют случайные факторы. Например, случайным является принадлежность многих каналов несанкционированного получения информации (КНПИ) к множеству КНПИ, потенциально возможных в том или ином компоненте КИС, принадлежность многих средств защиты к множеству средств, с помощью которых может быть эффективно перекрыт тот или иной КНПИ и т.п. Указанные элементы принадлежат соответствующим множествам лишь с некоторой вероятностью. Для описания таких систем в последние годы интенсивно развивается так называемая теория нечетких множеств. Имеются попытки использования методов данной теории для построения моделей систем защиты информации. Интерес к теории нечетких множеств постоянно усиливается, о чем свидетельствует экспоненциальный рост публикаций в этой области за последние тридцать лет (табл. 1). Издаются более десяти специализированных международных журналов по теории и применению нечетких множеств, среди которых "Fuzzy Sets and Systems" и "Applied Soft Computing" (издательство Elsevier Science), "Journal of Intelligent and Fuzzy Systems" (издательство IOS Press), "Intenational Journal of Uncertainty, Fuzziness and Knowledge-Based Systems" (издательство World Scientific), "IEEE Transactions on Fuzzy Systems" (издательство IEEE), "Soft Computing" (издательство Springler-Verlag). Много журналов публикуют статьи по нечетким множествам, среди них русскоязычные "Кибернетика и системный анализ", "Известия РАН. Теория и системы управления", "Автоматика и телемеханика", "Автоматика и вычислительная техника". Таблица 1 Количество публикаций, в названии которых встречаются слова "fuzzy" и "fuzzy control" (данные BISC - Berkeley Initiative in Soft Computing) Период База данных INSPEC (технические науки) База данных MathSciNet (математические науки) "fuzzy" "fuzzy control" "fuzzy" "fuzzy control" 1970-1979 569 38 443 1980-1989 2404 214 2465 39 1990-1999 23207 4689 5479 335 2000-20.11.2003 9945 >508 2865 нет данных Практическое применение теории нечетких множеств началось в середине семидесятых, когда Мамдани (Mamdani) и Ассилиан (Assilian) из Лондонского колледжа Королевы Мэри построили первый нечеткий контроллер для лабораторной модели парового двигателя. Концепцию первого нечеткого контроллера составляют идеи нечеткого логического вывода и нечеткого алгоритма, изложенные Заде в 1973 году. Первый промышленный нечеткий контроллер заработал в 1982 году в Дании Холмблад (Holmblad) и Остергард (Ostergaard) внедрили нечеткую логику в управление процессом обжига цемента. Тогда, в восьмидесятых, европейские и американские инженерные и научные сообщества весьма скептически восприняли новую теорию. Зато на Востоке нечеткая логика пошла "на ура". Для азиатов, воспитанных на восточной философии с ее неоднозначными и расплывчатыми категориями, нечеткая логика сразу стала своей, родной. В 1987 году фирма Hitachi разработала нечеткую систему управления движением электропоезда в метро города Сендай. В 1990 году в Японии уже зарегистрировано около 30 патентов, связанных с нечеткой логикой. В начале девяностых японцы поставили нечеткую логику "на конвейер" - началось серийное производство бытовых приборов с нечетким управлением: камеры с автоматической фокусировкой (Canon), кондиционеры воздуха (Mitsubishi), стиральные машины (Panasonic и Matshushita). Тогда же фирмы Honda и Nissan разработали автоматическую трансмиссию с нечетким управлением, а фирма Toshiba - нечеткий контроллер лифта. Нечеткая логика становится маркетинговым оружием на японском рынке - fuzzy-товары быстро раскупаются. В 1993 году Коско (Kosko) доказал теорему о нечеткой аппроксимации (FAT Fuzzy Approximation Theorem) , согласно которой, любая математическая система может быть аппроксимирована системой на нечеткой логике. Следовательно, с помощью естественно-языковых высказываний "Если то", с последующей их формализацией средствами теории нечетких множеств, можно сколько угодно точно отразить произвольную взаимосвязь "входы выход" без использования сложного аппарата дифференциального и интегрального исчислений, традиционно применяемого в управлении и идентификации. Практические успехи нечеткого управления получили теоретическое обоснование. Сегодня нечеткая логика рассматривается как стандартный метод моделирования и проектирования. В январе 1997 года язык нечеткого управления FCL Fuzzy Control Language внесен в Международный стандарт программируемых контроллеров IEC 1131-7. Системы на нечетких множествах разработаны и успешно внедрены в таких областях, как: медицинская диагностика, техническая диагностика, финансовый менеджмент, управление персоналом, биржевое прогнозирование, распознавание образов, разведка ископаемых, выявление мошенничества, управление компьютерными сетями, управление технологическими процессами, управление транспортом, поиск информации в Интернете, радиосвязь и телевидение. Спектр приложений очень широкий от бытовых видеокамер, пылесосов и стиральных машин до средств наведения ракет ПВО и управления боевыми вертолетами. По-прежнему лидирует Япония, в которой выпущено свыше 4800 "нечетких" патентов (в США около 1700 патентов). Практический опыт разработки систем на нечетких множествах свидетельствует, что сроки и стоимость их проектирования значительно ниже, чем при использовании традиционного математического аппарата, при этом обеспечивается требуемые уровни качества. Лотфи Это объясняется тем, что: 1) нечеткая логика позволяет по экспертным знаниям быстро разработать прототип технического устройства с последующим усложнением его функциональности; 2) модель на основе нечеткого логического вывода прозрачнее (проще для понимания), чем аналогичная модель на дифференциальных, разностных или иных уравнениях; 3) нечеткие модели проще реализовать аппаратно, при этом можно распараллелить вычисления. ЛЕКЦИЯ 11. ОЦЕНКИ ЗАЩИЩЕННОСТИ НА ОСНОВЕ МОДЕЛИ КОМПЛЕКСА МЕХАНИЗМОВ ЗАЩИТЫ. СЕМАНТИЧЕСКИЕ ПОКАЗАТЕЛИ ЗАЩИЩЕННОСТИ ИС. Для оценки защищенности системы проводят анализ ее уязвимостей. Под уязвимостями понимаются «слабые места» системы, которыми может воспользоваться злоумышленник как собственно для атаки, так и для сбора необходимой информации о системе для будущих атак. Анализ уязвимостей может быть двух видов: пассивный и активный. При пассивном анализе производится только сканирование системы — определяются элементы и механизмы системы, защита которых недостаточна, чем может воспользоваться злоумышленник. При этом также делаются предположения о возможности проведения вторжения. Активный анализ предполагает попытки проведения различного рода атак и, в большинстве случаев, является более достоверным и эффективным методом. Однако при его использовании есть вероятность выхода системы из строя. Практические исследования показали, что уязвимости можно разделить на два класса: • операционные дефекты (ошибки реализации); • ошибки администрирования. Операционные дефекты характеризуют технологическую безопасность информационного ресурса и являются результатом ошибок проектирования и реализации программного обеспечения АС. Для удобства создания систем зашиты и моделирования проникновения в АС целесообразно классифицировать ошибки проектирования по механизмам (подсистемам) безопасности системы. При этом основными типами операционных дефектов являются недостатки механизмов аутентификации, разграничения доступа, целостности данных, криптографии, а также сетевых протоколов и ошибки программной реализации. Ошибки администрирования характеризуют эксплуатационную безопасность и являются результатом некорректных настроек операционной системы и ее приложений по отношению к назначению АС и требованиям к ее безопасности. Причинами ошибок администрирования могут быть различные некомпетентные, халатные или злонамеренные действия администраторов и пользователей АС. Основными типами ошибок администрирования являются ошибки параметров подключения пользователей, настройки парольной защиты и использования легко подбираемых паролей, конфигурирования сервера, назначения полномочий. В настоящее время существуют специальные средства контроля защищенности. Кроме того, многие системы информационной безопасности имеют встроенные средства для осуществления такого контроля. В любом случае необходимо уделять достаточное внимание этому этапу создания и функционирования системы защиты, так как наличие системы защиты, в работе которой возможны серьезные сбои и ошибки, в некоторых случаях хуже ее отсутствия. Это связано с тем, что у пользователей появляется иллюзия защищенности, хотя на самом деле ситуация прямо противоположная. Таким образом, для грамотного выбора или построения системы защиты информации и поддержания ее функционирования необходимо обратить внимание на следующие моменты: — выявление всех возможных угроз защищаемой информации; • грамотное, полное и четкое формулирование политики безопасности организации в целом и вычислительной системы в частности; • комплексность построения системы защиты: она должна содержать полный набор необходимых механизмов и средств защиты и осуществлять их совместное использование; • необходимость постоянного слежения за работой системы защиты и ее периодических проверок; • правильный выбор фирмы-производителя системы защиты и ее отдельных компонентов: данная фирма должна хорошо зарекомендовать себя на рынке, желательно наличие большого опыта работы в данной области и широкой сети клиентов. Только при соблюдении перечисленных условий можно говорить об обеспечении определенного уровня информационной безопасности. Согласно модели комплекса механизмов защиты уровень защищенности зави­сит не только от числа механизмов защи­ты, но и от расположения механизмов защиты в структуре системы защиты информации. Анализ защищенности проводится в два этапа: • оценка защищенности, обеспечивае­мой отдельным механизмом; • оценка защищенности СЗИ в целом. На первом этапе определяется потен­циальная защищенность – рейтинг стойкости отдельного механизма защиты, производят его ранжирование в зависимости от уровня защищенности, который он спо­собен обеспечить. Защищенность информационной системы оценивают, полагая, что все механизмы защиты равноценны и участвуют в нейтрализации уг­роз. Для определения рейтинга Rs защищенности информационной системы суммируют рейтинги стойкости отдельных механизмов:  где mi — рейтинг стойкости i-го механизма защиты. Структурная модель системы защиты информации  учитывает структурные особенности информационной системы, например, наличие средств защиты на следующих уровнях: аппаратном, BIOS, операционная система, сетевом, СУБД, функционального ПО (рис. 11.1).  Рис. 11.1 Структурная модель системы защиты Механизмы защиты располагаются на соответствующих уровнях в соответствии с их назначени­ем. Если число уровней системы защиты информации равно j, а число различных механизмов составляет i, то можно сформировать ма­трицу рейтингов стойкости следующе­го вида: , где каждый столбец матрицы соответствует уровню системы защиты. Предполагается, что угроза с определенной ве­роятностью будет нейтрализована некоторым механизмом защиты на од­ном из уровней системы защиты информации.  Использование предложенной оценки защищенности информационной системы позво­ляет представлять результаты анали­за защищенности в количественной форме, что позволяет использовать рейтинговый показатель в качестве целевой функции для оптимизации распределения механизмов защиты по уровням системы защиты, при этом в качестве критерия  будет использоваться максимизация рейтинга Rs. К недостаткам этой модели можно отнести статичный характер оценки защищенности информационной системы, не учитывающей такие параметры как ущерб от реализации угроз информационной безопасности и частоту осуществления атак. Кроме того, предположение о снижении количества актуальных угроз по мере приближения к объекту защиты не всегда справедливо. ЛЕКЦИЯ 12. НЕЧЕТКИЕ ОЦЕНКИ ЗАЩИЩЕННОСТИ ИНФОРМАЦИОННЫХ СИСТЕМ. КОМПЛЕКСНЫЕ ОЦЕНКИ ЗАЩИЩЕННОСТИ ИС. Официально признаваемой оценкой защищенности ИС являются классы защищенности, описание которых приведено в стандартах защищенности. Отечественный стандарт ГОСТ / ИСО МЭК 15408 – 2002 «Общие критерии оценки безопасности информационных технологий» и его прототип - международный стандарт «Common Criteria for Information Technology Security Evaluation» (далее – ОК) обобщают подход к оценке защищенности на основе учета качественного состава механизмов и средств защиты. Рассмотренные в вышеназванных стандартах подходы обладают рядом недостатков: ·                    при наличии большого числа стандартов отсутствует единая терминология, которая отслеживает изменения в области защиты информации; ·                    предъявляются только требования по составу и проведению сертификации средств защиты информации, но отсутствуют количественные показатели и единые требования к функционированию СЗИ. Известные оценки защищенности АС исходят из наличия определенного набора средств и механизмов защиты, методик изготовления, эксплуатации и тестирования, позволяющих отнести то или иное устройство или ИС в целом к одному из дискретных уровней защищенности в соответствии с используемыми в данной стране стандартами . Для количественной оценки уровня защищенности используют рейтинговые показатели, которые учитывает распределение механизмов защиты по уровням иерархической модели СЗИ и изменение вероятности достижения злоумышленником объекта защиты в зависимости от уровня СЗИ . Предлагается при проведении инвестиционного ана­лиза СЗИ или для оценки ущерба в случае реализации угроз учитывать ущерб, как в стоимостном исчислении, так и не­материальный ущерб (табл. 1) , нане­сенный репутации, конкурентным воз­можностям хозяйствующего субъекта (ХС). Вводят семантические показатели «величина нематериального ущерба» и «вероятность нанесения ущерба» (табл. 2) , которые связаны с частотой реализации угрозы за конкретный период времени. Таблица 1. Величина ущерба Семантический показатель «величина нематериального ущерба» Ничтожный Ущербом можно пренебречь Незначительный Затраты на ликвидацию последствий реализации угрозы невелики Умеренный Ликвидация последствий реализации угрозы не связана с крупными затратами, но положение рынке ухудшается, часть клиентов теряется Серьезный Затрудняется выполнение критически важных задач. Утрата на длительный период положения на рынке. Ликвидация последствий угрозы связана со значительными финансовыми инвестициями Критический Реализация угрозы приводит к невозможности решения критически важных задач. Организация прекращает существование Таблица 2. Частота реализации угрозы Значение вероятности Семантическая характеристика реализации угрозы Нулевая Около нуля Угроза практически никогда не реализуется 1 раз за несколько лет Очень низкая Угроза реализуется редко 1 раз за год Низкая Скорее всего, угроза не реализуется 1 раз в месяц Средняя Скорее всего, угроза реализуется 1 раз в неделю Выше средней Угроза почти обязательно реализуется 1 раз за день Высокая Шансов на положительный исход нет   Предлагается осуществлять анализ вариантов СЗИ по критерию «стоимость/эффективность», учитывая соображения: ·стоимость СЗИ не должна превышать опреде­ленную сумму (как правило, не более 20% от стоимости системы ИС); ·  уровень ущерба не должен превышать заданное значение, например, «незначительный». Представленные оценки отражают статическое состояние объекта защиты, исходя из имеющихся в СЗИ механизмов защиты, не учитывают действительную загруженность МЗ по нейтрализации последствия компьютерных атак, динамику изменения угроз, возможность адаптации СЗИ к изменению угроз, не дают рекомендаций на изменение состава механизмов защиты и структуры СЗИ. Нечеткие оценки защищенности информационных систем. В работе защищенность определяется исходя из ущерба ИС, связанного с реализацией угроз, носящих случайный характер, который оценивается через коэффициенты опасности угроз. Коэффициенты опасности представляются нечеткими величинами, а показатель защищенности ИС определяется посредством матрицы нечетких отношений между коэффициентом опасности множества угроз и степенью защищенности ИС. Подход к оценке эффективности технической защиты инфор­мации (ТЗИ) в информационных системах основан на сравнении показателей защищенности без применения ТЗИ и с применением ТЗИ в условиях нечеткого представления о степени опасности комплекса ан­тропогенных и техногенных угроз. Под эффективностью понимают меру достижения цели ТЗИ. Оценка эффективности ТЗИ — процесс установления соответствия между результатом защиты и поставленной целью. С ростом сложности объектов анализа, состава и характеристик угроз (особенно угроз несанкционированного удаленного доступа) задача количественной оценки защищенности актуальна. Оценка эффективности ТЗИ возможна: 1) на основе сравнения значения показателя защищенности с нормативным (пороговым) значением; 2) на основе сравнения показателей защищенности информации без ТЗИ и в условиях ТЗИ. Оба подхода применяются на уровне частных моделей и методик. Для комплексной оценки эффективности первый подход является мало приемлемым, т. к. сложно определить допустимые уровни снижения защищенности информации от комплекса угроз. Второй подход применим при сравнительном анализе эффективности мер и средств защиты информации и не позволяет определить достаточность ТЗИ. Если защищенность информации оценивается показателем h0 (t) без принятия мер защиты и hТ3И(t) в условиях ТЗИ, то эффективность ТЗИ может быть оценена относительным показателем  Пусть известны возможные угрозы безопасности информации в ИС и любая из этих угроз проявляется и реализуется за рассматриваемый период t с некоторой вероятностью Рреал.u(t). Ущерб Du от реализации u-й угрозы является величиной случайной, распределенной в интервале [0,Dпр], где Dnp — уровень ущерба, превышение которого неприемлемо. Если ущерб от реализации угрозы превышает Dnp, то он принимается равным Dnр. Отношение Du/Dnp будет характеризовать уровень опасности u-й угрозы и вероятность, что ущерб будет не более Du. Вероятность, что уровень ущерба при реализации совокупности п из U возможных угроз не превысит величину DSn : или где l — вспомогательный параметр, КSn и Ки — отношения соответственно DSn и Du к Dnp назовем коэффициентами опасности угроз, так как они соответствуют уровню наноси­мого ущерба, вплоть до неприемлемого. Если рассматривать все U угроз и учесть, что коэффициенты опасности являются функциями времени, то последняя формула преобразуется к виду Мера опасности угрозы - четко заданная величина либо нечеткая величина, характеризующая суждение эксперта об опасности угрозы. В первом случае защищенность ИС м.б. оценена показателем — «степень защищенности» Данный показатель позволяет оценить эффективность ТЗИ как по всему множеству угроз, так и подмножеству угроз, составляющих определенную направленность: нарушение целостности, доступности или конфиден­циальности информации. Достоинство показателя — полиморфизм, исключающий корректи­ровку методов расчета в зависимости от состава угроз. Определение коэффициентов опасности угроз в виде четких значений основано на ана­литических соотношениях, связывающих эти коэффициенты с показателями ценности ин­формации. Такие показатели в виде коэффициентов важности могут быть определены на основе эвристического анализа и категорирования информации в ИС по важности. Пусть информация на объекте информатизации представлена в виде файлов и для каждого файла пользователь устанавливает категорию важности информа­ции. Например, м.б. введены 4 категории важности информации: 1 — особо важная, 2 — очень важная, 3 — важная, 4 — маловажная. При этом все угрозы разделяются на 3 группы: нарушение целостности, доступности и конфиденциальности информации. Пользо­вателем эвристически определяются коэффициенты важности f-го файла Vz (t,f) < 1, относящегося к z-й категории. Применительно к нарушению конфиденциальности информации соотношение для расчета коэффициентов опасности u-й угрозы имеет вид а для угроз, направленных на нарушение целостности и доступности информации, или для комплексных угроз коэффициент опасности где Zu — количество категорий важности информации, для которой u-я угроза представляет опасность; Fz — количество подлежащих защите файлов в системе, имеющих z-ю категорию важности; Pвост.f(t) — вероятность восстановления за рассматриваемый период времени t целостности (доступности) информации, содержащейся в f-м файле (если файл не подвержен воздействию или коэффициент важности содержащейся в нем информации равен нулю, то эта вероятность тождественно равна 1). При определении коэффициентов опасности угроз в виде нечетких величин необходимо проводить экспертный анализ опасности угроз. Такой подход может оказаться наиболее адекватным реальной опасности угроз, если анализ осуществляется высококвалифициро­ванными специалистами. Как правило, различные эксперты по-разному оценивают значение параметра и часто затрудняются задать конкретное число, поскольку существует много факторов, влияющих на оцениваемые величины и имеющих вероятностную природу. Для подобных ситуаций используется аппарат нечетких множеств, коэффициенты опасности задаются в виде нечетких чисел, способных принимать свои значения из определенного заданного интервала (множества) с различными значениями функций принадлежности Коэффициент опасности каждой угрозы описывается функцией принадлежности треугольной формы (рис. 12.1). Рис. 12.1Треугольное представление нечеткого числа. То есть представляется тройкой чисел, определяющих левую и правую границу области определения, а также значение, соответствующее максимальной истинности коэффициента опасности угрозы. Значения функции принадлежности mА(х) для этих точек задаются так, что для средней точки это значение наибольшее, а остальные два являются нулевыми. В соответствии с теорией нечетких множеств операции над значениями коэффициентов опасности Ки заменяются операциями над их функциями принадлежности mКи (Киi). При обработке результатов опроса экспертов функция принадлежности может потерять треугольный вид. Для случая задания коэффициентов опасности угроз нечеткими числами формула для показателя «степень защищенности» запишется в виде где операция ° умножения нечетких чисел производится по следующему правилу: . Назовем нечеткое множество КS, характеризующее опасности в ИС, пространством опасности (угроз) системы. Если между коэффициентом опасности множества угроз и показателем «степень защищенности» ИС имеется четкая зависимость, то она может быть представлена в простом виде Часто соотношение между коэффициентом опасности совокупности угроз и степенью защищенности ИС оказывается приблизительным. В этом случае необходимо определить причинные отношения между значениями этого коэффициента (предпосылками) и конечным результатом — степенью защищенности h (заключениями). Для этих целей как ключевой момент методики экспертного оценивания эффективности средств технической защиты инфор­мации вводится матрица нечетких отношений R размерностью n х m. В матрица нечетких отношений заключены правила, определяющие причинные отношения между каждым членом предпосылок КS и каждым членом заключений h(t) Элементы матрицы rij = mR (КS,h) должны отражать нечеткие отношения между КS и hi. Величину R можно рассматривать как нечеткое пространство на прямом произведении КS x h полного пространства предпосылок КS и полного пространства заключений h, a процесс получения нечеткого результата h с использованием данных КS и знания КSэт® hэт (эталонного преобразования) можно представить в виде: где знак • определяет операцию «max-min» композиции в качестве композиционного правила нечеткого вывода и операции взятия минимума в качестве нечеткой импликации Размерность матрицы нечетких отношений определяется количеством заданных числовых градаций коэффициента опасности и порогов функции принадлежности. Корректная формализация правил, с помощью которых формируется эта матрица, определит точность и достоверность конечного результата, являющегося выводом системы экспертного оценивания. Возможны несколько вариантов построения правил вывода в зависимости от важности объекта информатизации и отношения к нему экспертов. Однако наиболее широко в экспертных оценках используется набор правил, основанный на определении связи коэффициента КS и показателя защищенности системы h в виде пропорциональной зависимости с равномерным уменьшением достоверности оценки. В простейшем случае значения элементов матрицы нечеткого вывода рассчитываются по формуле Оценить эффективность ТЗИ можно, определяя степень защищенности h(t) в условиях отсутствия и применения мер ТЗИ. Для этого осуществляют дефаззификацию [11] одним из следующих способов; 1) задавшись требуемым уровнем функции принадлежности mh (h), проводят отсечение и выбирают первое приемлемое значение h 2) проводят отсечение по способу 1 и берут два крайних значения hн и hк. Тогда значение коэффициента защиты будет определяться как: со степенью достоверности: Зная нечеткие значения и функции принадлежности коэффициентов опасности угроз, можно с учетом вероятностей реализации угроз по правилам теории нечетких множеств рассчитать нечеткие значения степени защищенности объекта информатизации от комплекса угроз. Недостатками подобного оценивания являются статичность оценки защищенности и отсутствие взаимосвязи показателей защищенности с местоположением МЗ в структуре системы информационной безопасности (СИБ). Комплексные оценки защищенности ИС. Динамичный характер оценки защищенности ИС  обеспечивает модель адаптивной СИБ . Одним из компонентов СИБ является блок расчета показателей защищенности, который совместно с методикой оценки защищенности  ИС, позволяет: · обеспечить близкое к оптимальному отношение «стоимость/ эффективность» СИБ за счет использования только необходимых МЗ, · отслеживать динамику использования МЗ при изменении множества угроз, ·формировать спецификацию требований на отсутствующие МЗ, ·оценивать защищенность ИС через величины ожидаемого ущерба и интегральные показатели активности МЗ, распределенных по СИБ. Решение о расширении классификаций угроз и МЗ производится в соответствии с системой оценок достоверности нейтрализации угроз в разрезе отдельных МЗ или уровней СИБ и аналогичных оценок предполагаемого ущерба, соотносимых с отдельными МЗ или уровням СИБ. Ущерб рассматривается в относительных величинах, к примеру, по отношению к значению допустимого ущерба в ИС хозяйствующего субъекта. Результаты экспертных оценок представляют в виде матрицы достоверности «угрозы – уровни СИБ»: где m – число механизмов защиты, n - число уровней СИБ. Активность уровня СИБ по нейтрализации угроз, входящих в систему предикатных правил в качестве посылок, определяют строкой интегральных показателей строкой показателей значимости уровня в структуре СИБ: , нормированных по значению максимального из  или по значению суммы элементов строки показателей значимости . Сопоставление интегральных показателей в пределах строки позволяет выявить наиболее активные уровни модели СИБ по нейтрализации угроз. Аналогично можно получить столбец интегральных показателей активности использования механизма защиты на всех уровнях СИБ: . Сопоставление интегральных показателей в пределах столбца дает возможность выявить наиболее активно используемые МЗ в структуре СИБ. Анализ интегральных показателей позволяет обосновать целесообразность использования МЗ в составе соответствующего уровня СИБ. Использование экспертных оценок и отражение в структуре нейронечеткой сети опыта экспертов ИБ сопровождают проверкой на непротиворечивость результатов опроса экспертов. Непротиворечивость экспертных оценок может быть обеспечена применением, например, метода экспертных оценок матрицы нечетких отношений [8] или метода на основе расчета максимального собственного значения матрицы парных сравнений [13]. Приведенные показатели будут более информативными, если учитывать не только достоверность использования МЗ в структуре СИБ, но и показатели предполагаемого ущерба, возникающего при реализации угроз в ИС и который может быть предотвращен системой информационной безопасности. С этой целью по аналогии с оценку защищенности можно косвенно связать с предотвращением ущерба и использовать экспертные оценки для сопоставления множества угроз с потенциальным ущербом от их реализации  и размера ущерба с местом реализации угрозы в структуре ИС. Показатели применимы для оценки защищенности систем по множеству известных угроз и по подмножеству угроз: нарушения целостности, конфиденциальности, доступности информации. Проведенный анализ показал необходимость разработки обобщенного количественного показателя для оценки свойства «защищенность» ИС, который должен объединить положительные стороны известных подходов с целью его дальнейшего использования в качестве целевой функции для оптимизации структуры информационной системы по критерию «стоимость/защищенность». Кроме того, необходима разработка процесса двухступенчатой оптимизации средств мониторинга безопасности ИС, включающего: · оптимизацию набора функций безопасности объекта оценки в условиях бюджетных ограничений; · оптимизацию размещения механизмов защиты в структуре системы информационной безопасности по критерию максимизации рейтингового показателя защищенности ИС. С ростом сложности объектов информатизации, изменением множества и характера угроз информационной безопасности, особенно угроз несанкционированного удаленного доступа к ресурсам и процессами критических информационных систем, задача количественной оценки защищенности является актуальной. Корректная оценка защищенности критических информационных систем необходима для выполнения сравнения аналогичных по назначению и уровню сложности систем либо для мониторинга динамики уровня защищенности конкретной информационной системы во времени.