|
|
Лекции по защите информации. Информация о курсе Понятие информационной безопасности
Попытаемся применить объектно-ориентированный подход к вопросам информационной безопасности.
Проблема обеспечения информационной безопасности - комплексная, защищать приходится сложные системы, и сами защитные средства тоже сложны, поэтому нам понадобятся все введенные понятия. Начнем с понятия грани.
Фактически три грани уже были введены: это доступность, целостность и конфиденциальность. Их можно рассматривать относительно независимо, и считается, что если все они обеспечены, то обеспечена и ИБ в целом (то есть субъектам информационных отношений не будет нанесен неприемлемый ущерб).
Таким образом, мы структурировали нашу цель. Теперь нужно структурировать средства ее достижения. Введем следующие грани:
законодательные меры обеспечения информационной безопасности;
административные меры (приказы и другие действия руководства организаций, связанных с защищаемыми информационными системами);
процедурные меры (меры безопасности, ориентированные на людей);
программно-технические меры.
В дальнейшей части курса мы поясним подробнее, что понимается под каждой из выделенных граней. Здесь же отметим, что, в принципе, их можно рассматривать и как результат варьирования уровня детализации (по этой причине мы будем употреблять словосочетания "законодательный уровень", "процедурный уровень" и т.п.). Законы и нормативные акты ориентированы на всех субъектов информационных отношений независимо от их организационной принадлежности (это могут быть как юридические, так и физические лица) в пределах страны (международные конвенции имеют даже более широкую область действия), административные меры - на всех субъектов в пределах организации, процедурные – на отдельных людей (или небольшие категории субъектов), программно-технические – на оборудование и программное обеспечение. При такой трактовке в переходе с уровня на уровень можно усмотреть применение наследования (каждый следующий уровень не отменяет, а дополняет предыдущий), а также полиморфизма (субъекты выступают сразу в нескольких ипостасях - например, как инициаторы административных мер и как обычные пользователи, обязанные этим мерам подчиняться).
Очевидно, для всех выделенных, относительно независимых граней действует принцип инкапсуляции (это и значит, что грани "относительно независимы"). Более того, эти две совокупности граней можно назвать ортогональными, поскольку для фиксированной грани в одной совокупности (например, доступности) грани в другой совокупности должны пробегать все множество возможных значений (нужно рассмотреть законодательные, административные, процедурные и программно-технические меры). Ортогональных совокупностей не должно быть много; думается, двух совокупностей с числом элементов, соответственно, 3 и 4 уже достаточно, так как они дают 12 комбинаций.
Продемонстрируем теперь, как можно рассматривать защищаемую ИС, варьируя уровень детализации.
Пусть интересы субъектов информационных отношений концентрируются вокруг ИС некой организации, располагающей двумя территориально разнесенными производственными площадками, на каждой из которых есть серверы, обслуживающие своих и внешних пользователей, а также пользователи, нуждающиеся во внутренних и внешних сервисах. Одна из площадок оборудована внешним подключением (то есть имеет выход в Internet).
При взгляде с нулевым уровнем детализации мы увидим лишь то, что у организации есть информационная система (см. рис. 2.1).
Рис. 2.1. ИС при рассмотрении с уровнем детализации 0.
Подобная точка зрения может показаться несостоятельной, но это не так. Уже здесь необходимо учесть законы, применимые к организациям, располагающим информационными системами. Возможно, какую-либо информацию нельзя хранить и обрабатывать на компьютерах, если ИС не была аттестована на соответствие определенным требованиям. На административном уровне могут быть декларированы цели, ради которых создавалась ИС, общие правила закупок, внедрения новых компонентов, эксплуатации и т.п. На процедурном уровне нужно определить требования к физической безопасности ИС и пути их выполнения, правила противопожарной безопасности и т.п. На программно-техническом уровне могут быть определены предпочтительные аппаратно-программные платформы и т.п.
По каким критериям проводить декомпозицию ИС – в значительной степени дело вкуса. Будем считать, что на первом уровне детализации делаются видимыми сервисы и пользователи, точнее, разделение на клиентскую и серверную часть (рис. 2.2).
Рис. 2.2. ИС при рассмотрении с уровнем детализации 1.
На этом уровне следует сформулировать требования к сервисам (к самому их наличию, к доступности, целостности и конфиденциальности предоставляемых информационных услуг), изложить способы выполнения этих требований, определить общие правила поведения пользователей, необходимый уровень их предварительной подготовки, методы контроля их поведения, порядок поощрения и наказания и т.п. Могут быть сформулированы требования и предпочтения по отношению к серверным и клиентским платформам.
На втором уровне детализации мы увидим следующее (см. рис. 2.3).
Рис. 2.3. ИС при рассмотрении с уровнем детализации 2.
На этом уровне нас все еще не интересует внутренняя структура ИС организации, равно как и детали Internet. Констатируется только существование связи между этими сетями, наличие в них пользователей, а также предоставляемых и внутренних сервисов. Что это за сервисы, пока неважно.
Находясь на уровне детализации 2, мы должны учитывать законы, применимые к организациям, ИС которых снабжены внешними подключениями. Речь идет о допустимости такого подключения, о его защите, об ответственности пользователей, обращающихся к внешним сервисам, и об ответственности организаций, открывающих свои сервисы для внешнего доступа. Конкретизация аналогичной направленности, с учетом наличия внешнего подключения, должна быть выполнена на административном, процедурном и программно-техническом уровнях.
Обратим внимание на то, что контейнер (в смысле компонентной объектной среды) "ИС организации" задает границы контролируемой зоны, в пределах которых организация проводит определенную политику. Internet живет по другим правилам, которые организация должна принимать, как данность.
Увеличивая уровень детализации, можно разглядеть две разнесенные производственные площадки и каналы связи между ними, распределение сервисов и пользователей по этим площадкам и средства обеспечения безопасности внутренних коммуникаций, специфику отдельных сервисов, разные категории пользователей и т.п. Мы, однако, на этом остановимся.
Недостатки традиционного подхода к информационной безопасности с объектной точки зрения
Исходя из основных положений объектно-ориентированного подхода, следует в первую очередь признать устаревшим традиционное деление на активные и пассивные сущности (субъекты и объекты в привычной для дообъектной ИБ терминологии). Подобное деление устарело, по крайней мере, по двум причинам.
Во-первых, в объектном подходе пассивных объектов нет. Можно считать, что все объекты активны одновременно и при необходимости вызывают методы друг друга. Как реализованы эти методы (и, в частности, как организован доступ к переменным и их значениям) - внутреннее дело вызываемого объекта; детали реализации скрыты, инкапсулированы. Вызывающему объекту доступен только предоставляемый интерфейс.
Во-вторых, нельзя сказать, что какие-то программы (методы) выполняются от имени пользователя. Реализации объектов сложны, так что последние нельзя рассматривать всего лишь как инструменты выполнения воли пользователей. Скорее можно считать, что пользователь прямо или (как правило) косвенно, на свой страх и риск, "просит" некоторый объект об определенной информационной услуге. Когда активизируется вызываемый метод, объект действует скорее от имени (во всяком случае, по воле) своего создателя, чем от имени вызвавшего его пользователя. Можно считать, что объекты обладают достаточной "свободой воли", чтобы выполнять действия, о которых пользователь не только не просил, но даже не догадывается об их возможности. Особенно это справедливо в сетевой среде и для программного обеспечения (ПО), полученного через Internet, но может оказаться верным и для коммерческого ПО, закупленного по всем правилам у солидной фирмы.
Для иллюстрации приведем следующий гипотетический пример. Банк, ИС которого имеет соединение с Internet, приобрел за рубежом автоматизированную банковскую систему (АБС). Только спустя некоторое время в банке решили, что внешнее соединение нуждается в защите, и установили межсетевой экран.
Изучение регистрационной информации экрана показало, что время от времени за рубеж отправляются IP-пакеты, содержащие какие-то непонятные данные (наверное, зашифрованные, решили в банке). Стали разбираться, куда же пакеты направляются, и оказалось, что идут они в фирму, разработавшую АБС. Возникло подозрение, что в АБС встроена закладка, чтобы получать информацию о деятельности банка. Связались с фирмой; там очень удивились, поначалу все отрицали, но в конце концов выяснили, что один из программистов не убрал из поставленного в банк варианта отладочную выдачу, которая была организована через сеть (как передача IP-пакетов специфического вида, с явно заданным IP-адресом рабочего места этого программиста). Таким образом, никакого злого умысла не было, однако некоторое время информация о платежах свободно гуляла по сетям.
В дальнейшей части курса, в лекции, посвященной разграничению доступа, мы обсудим, как можно кардинальным образом решить подобные проблемы. Здесь отметим лишь, что при определении допустимости доступа важно не только (и не столько), кто обратился к объекту, но и то, какова семантика действия. Без привлечения семантики нельзя определить так называемые "троянские программы", выполняющие, помимо декларированных, некоторые скрытые (обычно негативные) действия.
По-видимому, следует признать устаревшим и положение о том, что разграничение доступа направлено на защиту от злоумышленников. Приведенный выше пример показывает, что внутренние ошибки распределенных ИС представляют не меньшую опасность, а гарантировать их отсутствие в сложных системах современная технология программирования не позволяет.
В дообъектной ИБ одним из важнейших требований является безопасность повторного использования пассивных сущностей (таких, например, как динамически выделяемые области памяти). Очевидно, подобное требование вступает в конфликт с таким фундаментальным принципом, как инкапсуляция. Объект нельзя очистить внешним образом (заполнить нулями или случайной последовательностью бит), если только он сам не предоставляет соответствующий метод. При наличии такого метода надежность очистки зависит от корректности его реализации и вызова.
Одним из самых прочных стереотипов среди специалистов по ИБ является трактовка операционной системы как доминирующего средства безопасности. На разработку защищенных ОС выделяются значительные средства, зачастую в ущерб остальным направлениям защиты и, следовательно, в ущерб реальной безопасности. В современных ИС, выстроенных в многоуровневой архитектуре клиент/сервер, ОС не контролирует объекты, с которыми работают пользователи, равно как и действия самих пользователей, которые регистрируются и учитываются прикладными средствами. Основной функцией безопасности ОС становится защита возможностей, предоставляемых привилегированным пользователям, от атак пользователей обычных.
Это важно, но безопасность такими мерами не исчерпывается. Далее мы рассмотрим подход к построению программно-технического уровня ИБ в виде совокупности сервисов безопасности.
|
|
Знание возможных угроз, а также уязвимых мест защиты, которые эти угрозы обычно эксплуатируют, необходимо для того, чтобы выбирать наиболее экономичные средства обеспечения безопасности.
|
|
|
|
Основные определения и критерии классификации угроз
Угроза - это потенциальная возможность определенным образом нарушить информационную безопасность.
Попытка реализации угрозы называется атакой, а тот, кто предпринимает такую попытку, - злоумышленником. Потенциальные злоумышленники называются источниками угрозы.
Чаще всего угроза является следствием наличия уязвимых мест в защите информационных систем (таких, например, как возможность доступа посторонних лиц к критически важному оборудованию или ошибки в программном обеспечении).
Промежуток времени от момента, когда появляется возможность использовать слабое место, и до момента, когда пробел ликвидируется, называется окном опасности, ассоциированным с данным уязвимым местом. Пока существует окно опасности, возможны успешные атаки на ИС.
Если речь идет об ошибках в ПО, то окно опасности "открывается" с появлением средств использования ошибки и ликвидируется при наложении заплат, ее исправляющих.
Для большинства уязвимых мест окно опасности существует сравнительно долго (несколько дней, иногда - недель), поскольку за это время должны произойти следующие события:
должно стать известно о средствах использования пробела в защите;
должны быть выпущены соответствующие заплаты;
заплаты должны быть установлены в защищаемой ИС.
Мы уже указывали, что новые уязвимые места и средства их использования появляются постоянно; это значит, во-первых, что почти всегда существуют окна опасности и, во-вторых, что отслеживание таких окон должно производиться постоянно, а выпуск и наложение заплат - как можно более оперативно.
Отметим, что некоторые угрозы нельзя считать следствием каких-то ошибок или просчетов; они существуют в силу самой природы современных ИС. Например, угроза отключения электричества или выхода его параметров за допустимые границы существует в силу зависимости аппаратного обеспечения ИС от качественного электропитания.
Рассмотрим наиболее распространенные угрозы, которым подвержены современные информационные системы. Иметь представление о возможных угрозах, а также об уязвимых местах, которые эти угрозы обычно эксплуатируют, необходимо для того, чтобы выбирать наиболее экономичные средства обеспечения безопасности. Слишком много мифов существует в сфере информационных технологий (вспомним все ту же "Проблему 2000"), поэтому незнание в данном случае ведет к перерасходу средств и, что еще хуже, к концентрации ресурсов там, где они не особенно нужны, за счет ослабления действительно уязвимых направлений.
Подчеркнем, что само понятие "угроза" в разных ситуациях зачастую трактуется по-разному. Например, для подчеркнуто открытой организации угроз конфиденциальности может просто не существовать - вся информация считается общедоступной; однако в большинстве случаев нелегальный доступ представляется серьезной опасностью. Иными словами, угрозы, как и все в ИБ, зависят от интересов субъектов информационных отношений (и от того, какой ущерб является для них неприемлемым).
Мы попытаемся взглянуть на предмет с точки зрения типичной (на наш взгляд) организации. Впрочем, многие угрозы (например, пожар) опасны для всех.
Угрозы можно классифицировать по нескольким критериям:
по аспекту информационной безопасности (доступность, целостность, конфиденциальность), против которого угрозы направлены в первую очередь;
по компонентам информационных систем, на которые угрозы нацелены (данные, программы, аппаратура, поддерживающая инфраструктура);
по способу осуществления (случайные/преднамеренные действия природного/техногенного характера);
по расположению источника угроз (внутри/вне рассматриваемой ИС).
В качестве основного критерия мы будем использовать первый (по аспекту ИБ), привлекая при необходимости остальные.
Наиболее распространенные угрозы доступности
Самыми частыми и самыми опасными (с точки зрения размера ущерба) являются непреднамеренные ошибки штатных пользователей, операторов, системных администраторов и других лиц, обслуживающих информационные системы.
Иногда такие ошибки и являются собственно угрозами (неправильно введенные данные или ошибка в программе, вызвавшая крах системы), иногда они создают уязвимые места, которыми могут воспользоваться злоумышленники (таковы обычно ошибки администрирования). По некоторым данным, до 65% потерь - следствие непреднамеренных ошибок.
Пожары и наводнения не приносят столько бед, сколько безграмотность и небрежность в работе.
Очевидно, самый радикальный способ борьбы с непреднамеренными ошибками - максимальная автоматизация и строгий контроль.
Другие угрозы доступности классифицируем по компонентам ИС, на которые нацелены угрозы:
отказ пользователей;
внутренний отказ информационной системы;
отказ поддерживающей инфраструктуры.
Обычно применительно к пользователям рассматриваются следующие угрозы:
нежелание работать с информационной системой (чаще всего проявляется при необходимости осваивать новые возможности и при расхождении между запросами пользователей и фактическими возможностями и техническими характеристиками);
невозможность работать с системой в силу отсутствия соответствующей подготовки (недостаток общей компьютерной грамотности, неумение интерпретировать диагностические сообщения, неумение работать с документацией и т.п.);
невозможность работать с системой в силу отсутствия технической поддержки (неполнота документации, недостаток справочной информации и т.п.).
Основными источниками внутренних отказов являются:
отступление (случайное или умышленное) от установленных правил эксплуатации;
выход системы из штатного режима эксплуатации в силу случайных или преднамеренных действий пользователей или обслуживающего персонала (превышение расчетного числа запросов, чрезмерный объем обрабатываемой информации и т.п.);
ошибки при (пере)конфигурировании системы;
отказы программного и аппаратного обеспечения;
разрушение данных;
разрушение или повреждение аппаратуры.
По отношению к поддерживающей инфраструктуре рекомендуется рассматривать следующие угрозы:
нарушение работы (случайное или умышленное) систем связи, электропитания, водо- и/или теплоснабжения, кондиционирования;
разрушение или повреждение помещений;
невозможность или нежелание обслуживающего персонала и/или пользователей выполнять свои обязанности (гражданские беспорядки, аварии на транспорте, террористический акт или его угроза, забастовка и т.п.).
Весьма опасны так называемые "обиженные" сотрудники - нынешние и бывшие. Как правило, они стремятся нанести вред организации-"обидчику", например:
испортить оборудование;
встроить логическую бомбу, которая со временем разрушит программы и/или данные;
удалить данные.
Обиженные сотрудники, даже бывшие, знакомы с порядками в организации и способны нанести немалый ущерб. Необходимо следить за тем, чтобы при увольнении сотрудника его права доступа (логического и физического) к информационным ресурсам аннулировались.
Опасны, разумеется, стихийные бедствия и события, воспринимаемые как стихийные бедствия,- пожары, наводнения, землетрясения, ураганы. По статистике, на долю огня, воды и тому подобных "злоумышленников" (среди которых самый опасный - перебой электропитания) приходится 13% потерь, нанесенных информационным системам.
| |
|
|
Скачать 1.22 Mb.