После завершения формирования политики безопасности, можно приступать к составлению программы ее реализации и собственно к реальному воплощению этой программы. Проведение политики безопасности в жизнь требует использования трех видов регуляторов - управленческих, операционных и программно-технических. Продолжая начатое в предыдущих номерах журнала [1] изложение по основам информационной безопасности остановимся сегодня на управленческом аспекте реализации программы безопасности. Чтобы понять и реализовать любую программу, ее целесообразно структурировать по уровням, обычно в соответствии со структурой организации. В простейшем и самом распространенном случае достаточно двух уровней - верхнего, или центрального, который охватывает всю организацию, и нижнего, или сервисного, который относится к отдельным сервисам или группам однородных сервисов.
Уровни структуризации программы
Программу верхнего уровня возглавляет лицо, отвечающее за информационную безопасность организации. У этой программы следующие главные цели:
- управление рисками: оценка рисков, выбор эффективных средств защиты;
- координация деятельности в области информационной безопасности, пополнение и распределение ресурсов;
- стратегическое планирование;
- контроль деятельности в области информационной безопасности.
Девиз управленческого аспекта можно сформулировать как "эффективность и экономия". Управление должно быть организовано так, чтобы исключить дублирование в деятельности сотрудников организации и в максимальной степени использовать знания каждого из них. Например, если одно из подразделений специализируется на UNIX-системах, а в других такие системы установлены в небольшом числе экземпляров, нет смысла всем становиться специалистами по UNIX-защите - лучше вменить в обязанность сотрудникам первого подразделения следить за всеми UNIX-системами, установленными в организации. Правда, отсутствие дублирования, вообще говоря, противоречит надежности. Если в организации есть специалист, знания которого уникальны, его временное отсутствие или увольнение могут стать тяжелой потерей. Вероятно, лучшее "лекарство от незаменимости" - документирование накопленных знаний и освоенных процедур.
В рамках программы верхнего уровня принимаются стратегические решения по безопасности, оцениваются технологические новинки. Информационные технологии развиваются очень быстро, и необходимо иметь четкую политику отслеживания и внедрения новых средств.
Контроль деятельности в области безопасности имеет двоякую направленность. Во-первых, необходимо гарантировать, что действия организации не противоречат законам. Обязательны при этом контакты с внешними контролирующими организациями. Во-вторых, нужно постоянно отслеживать состояние безопасности внутри организации, реагировать на случаи нарушений, дорабатывать защитные меры с учетом изменения обстановки.
Следует подчеркнуть, что программа верхнего уровня должна занимать четко определенное место в деятельности организации, она должна официально приниматься и поддерживаться руководством, у нее должны быть определенные штаты и бюджет. Без подобной поддержки распоряжения "офицеров безопасности" останутся пустым звуком.
Цель программы нижнего уровня - обеспечить надежную и экономичную защиту конкретного сервиса или группы однородных сервисов. На этом уровне решается, какие механизмы защиты использовать, закупаются и устанавливаются технические средства, выполняется повседневное администрирование, отслеживается состояние слабых мест и т.п. Обычно за программу нижнего уровня отвечают администраторы сервисов.
Необходимо, однако, сделать одну оговорку. Программа безопасности не должна превращаться в набор технических средств, встроенных в систему - иначе она потеряет независимость и, как следствие, авторитет, высшее руководство забудет про нее и перестанет выделять ресурсы. У защиты есть много управленческих и операционных аспектов, и об этом следует постоянно помнить.
Управление рисками
Деятельность любой организации подвержена множеству рисков. Суть работы по управлению рисками состоит в том, чтобы оценить их размер, выработать меры по его уменьшению и затем убедиться, что риски заключены в приемлемые рамки. Таким образом, управление рисками включает в себя два вида деятельности:
- оценка рисков;
- выбор эффективных и экономичных защитных регуляторов.
Процесс управления рисками можно подразделить на следующие этапы:
- выбор анализируемых объектов и степени детальности их рассмотрения;
- выбор методологии оценки рисков;
- идентификация активов;
- анализ угроз и их последствий, определение слабостей в защите;
- оценка рисков;
- выбор защитных мер;
- реализация и проверка выбранных мер;
- оценка остаточного риска.
Этапы f и g относятся к выбору защитных регуляторов, остальные - к оценке рисков.
Уже само перечисление этапов показывает, что управление рисками - процесс циклический. По существу, последний этап - это оператор конца цикла, предписывающий вернуться к началу. Риски нужно контролировать постоянно, периодически проводя их переоценку. Отметим, что добросовестно выполненная и тщательно документированная первая оценка может существенно упростить последующую деятельность.
Выбор анализируемых объектов и степени детальности их рассмотрения - первый шаг в оценке рисков. Для небольшой организации допустимо рассматривать всю информационную инфраструктуру; однако если организации крупная, всеобъемлющая оценка может потребовать неприемлемых затрат времени и сил. В таком случае следует сосредоточиться на наиболее важных сервисах, заранее соглашаясь с приближенностью итоговой оценки. Если важных сервисов все еще много, то выбираются те из них, риски для которых заведомо велики или неизвестны.
Вообще говоря, уязвимым является каждый компонент информационной системы - от куска сетевого кабеля, который могут прогрызть мыши, до базы данных, которая может быть разрушена из-за неумелых действий администратора. Как правило, в сферу анализа невозможно включить каждый винтик и каждый байт. Приходится останавливаться на некотором уровне детализации, опять-таки отдавая себе отчет в приближенности оценки. Для новых систем предпочтителен детальный анализ; старая система, подвергшаяся небольшим модификациям, может быть проанализирована более поверхностно.
Очень важно выбрать разумную методологию оценки рисков. Целью оценки является получение ответа на два вопроса: приемлемы ли существующие риски, и если нет, то какие защитные средства экономически выгодно использовать. Значит, оценка должна быть количественной, допускающей сопоставление с заранее выбранными границами допустимости и расходами на реализацию новых регуляторов безопасности. Управление рисками - типичная оптимизационная задача, и существует довольно много программных средств, способных помочь в ее решении. Принципиальная трудность, однако, состоит в неточности исходных данных. Можно, конечно, попытаться получить для всех анализируемых величин денежное выражение, просчитать все с точностью до копейки, но большого смысла в этом нет. Практичнее пользоваться условными единицами. В простейшем и вполне допустимом случае можно пользоваться трехбалльной шкалой. Далее будет показано, как это делается.
При идентификации активов - тех ценностей, которые организация пытается защитить, следует, конечно, учитывать не только компоненты информационной системы, но и поддерживающую инфраструктуру, персонал, а также нематериальные ценности, в том числе репутацию компании. Тем не менее, одним из главных результатов процесса идентификации активов является получение детальной информационной структуры организации и способов ее использования.
Если информационной основой организации является локальная сеть, то в число аппаратных активов следует включить компьютеры, периферийные устройства, внешние интерфейсы, кабельное хозяйство и активное сетевое оборудование. К программным активам, вероятно, будут отнесены операционные системы (сетевая, серверные и клиентские), прикладное программное обеспечение, инструментальные средства, программы управления сетью и отдельными системами. Важно зафиксировать в каких узлах сети хранится программное обеспечение и из каких узлов используется. Третьим видом информационных активов являются данные, которые хранятся, обрабатываются и передаются по сети. Следует классифицировать данные по типам и степени конфиденциальности, выявить места их хранения и обработки, а также способы доступа к ним. Все это важно для оценки последствий нарушений информационной безопасности.
Управление рисками - процесс далеко не линейный. Практически все его этапы связаны между собой, и по завершении почти любого из них может выявиться необходимость возврата к предыдущему. Так, при идентификации активов может возникнуть понимание, что выбранные границы анализа следует расширить, а степень детализации - увеличить. Особенно труден первичный анализ, когда многократные возвраты к началу неизбежны.
Этапы, предшествующие анализу угроз, можно считать подготовительными, поскольку, строго говоря, они впрямую не связаны с рисками. Риск появляется там, где есть угрозы.
Краткий перечень наиболее распространенных угроз уже приводился ранее. К сожалению, на практике угроз гораздо больше, причем далеко не все они обязательно связаны с компьютерами. Так, вполне реальной угроза - мыши и тараканы в помещениях, занимаемых организацией. Первые могут повредить кабели, вторые вызвать короткое замыкание. Как правило, наличие той или иной угрозы является следствием слабостей в защите информационной системы, которые, в свою очередь, объясняются отсутствием некоторых сервисов безопасности или недостатками в реализующих их защитных механизмах. Опасность повреждения кабелей проистекает не только из-за мышей, но и из отсутствия или недостаточной прочности защитной оболочки.
Первый шаг в анализе угроз - их идентификация. Анализируемые виды угроз следует выбрать из соображений здравого смысла (оставив вне поля зрения, например, землетрясения или захват организации террористами), но в пределах выбранных видов необходимо провести максимально полное рассмотрение.
Целесообразно выявлять не только сами угрозы, но и источники их возникновения - это поможет в выборе дополнительных средств защиты. Например, нелегальный вход в систему может стать следствием воспроизведения начального диалога, подбора пароля или подключения к сети неавторизованного оборудования. Очевидно, что для противодействия каждому из перечисленных способов нелегального входа нужны свои механизмы безопасности.
После идентификации угрозы необходимо оценить вероятность ее осуществления. Допустимо использовать при этом трехбалльную шкалу: низкая -f 1, средняя - 2 и высокая - 3 вероятность.
Кроме вероятности осуществления важен размер потенциального ущерба. Например, пожары бывают нечасто, но ущерб от каждого из них, как правило, велик. Тяжесть ущерба также можно оценить по трехбалльной шкале. Оценивая тяжесть ущерба, необходимо иметь в виду не только непосредственные расходы на замену оборудования или восстановление информации, но и более отдаленные, в частности подрыв репутации, ослабление позиций на рынке и т.п. Пусть, например, в результате дефектов в управлении доступом к бухгалтерской информации сотрудники получили возможности корректировать данные о собственной заработной плате. Следствием такого состояния дел может стать не только перерасход бюджетных или корпоративных средств, но и полное разложение коллектива, грозящее развалом организации.
Слабости обладают свойством притягивать к себе не только злоумышленников, но и относительно честных людей. Не всякий устоит перед искушением немного увеличить свою зарплату, если имеется уверенность, что это сойдет в рук. Поэтому, оценивая вероятность осуществления угроз, целесообразно исходить не только из среднестатистических данных, но учитывать также специфику конкретных информационных систем. Если в подвале дома, занимаемого организацией, располагается сауна, а сам дом имеет деревянные перекрытия, то вероятность пожара, к сожалению, оказывается существенно выше средней.
Когда накоплены исходные данные и оценена степень неопределенности, можно переходить к обработке информации - собственно к оценке рисков. Вполне допустимо применить такой простой метод, как умножение вероятности осуществления угрозы на предполагаемый ущерб. Если для вероятности и ущерба использовать трехбалльную шкалу, то возможных произведений будет шесть: 1, 2, 3, 4, 6 и 9. Первые два результата можно отнести к низкому риску, третий и четвертый - к среднему, два последних - к высокому, после чего появляется возможность снова привести их к трехбалльной шкале. По этой шкале и следует оценивать приемлемость рисков. Правда, граничные случаи, когда вычисленная величина совпала с приемлемой, целесообразно рассматривать более тщательно - вследствие приближенного характера результата.
Если какие-либо риски оказались недопустимо высокими, необходимо реализовать дополнительные защитные меры. Как правило, для ликвидации или сглаживания слабости, сделавшей реальной опасную угрозу, существует несколько механизмов безопасности, отличающихся эффективностью и стоимостью. Например, если велика вероятность нелегального входа в систему, можно приказать пользователям выбирать длинные пароли, задействовать программу генерации паролей или закупить интегрированную систему аутентификации на основе интеллектуальных карт. Если имеется вероятность умышленного повреждения сервера баз данных, что грозит серьезными последствиями, можно врезать замок в дверь комнаты или поставить около каждого сервера по охраннику.
Оценивая стоимость защитных мер, приходится, разумеется, учитывать не только прямые расходы на закупку оборудования и/или программ, но и расходы на внедрение новинки и, в частности, на обучение и переподготовку персонала. Эту стоимость также можно выразить по трехбалльной шкале и затем сопоставить ее с разностью между вычисленным и приемлемым риском. Если по этому показателю новое средство оказывается экономически выгодным, его можно принять к дальнейшему рассмотрению (подходящих средств, вероятно, будет несколько). Однако если средство окажется дорогим, его не следует сразу отбрасывать, памятуя о приближенности расчетов.
Выбирая подходящий способ защиты, целесообразно учитывать возможность экранирования одним сервисом безопасности сразу нескольких прикладных сервисов. Так поступили в Массачусетском технологическом институте, защитив несколько тысяч компьютеров сервером аутентификации Kerberos.
Важным обстоятельством является совместимость нового средства со сложившейся операционной и аппаратно-программной структурой, а также с традициями организации. Меры безопасности, как правило, носят недружественный характер, что может отрицательно сказаться на энтузиазме сотрудников. Порой сохранение духа открытости важнее минимизации материальных потерь. Впрочем, такого рода ориентиры должны быть расставлены в политике безопасности верхнего уровня.
Можно представить себе ситуацию, когда для уменьшения риска не существует эффективных и приемлемых по цене мер. Например, компания, базирующаяся в сейсмически опасной зоне, не всегда может позволить себе строительство защищенной штаб-квартиры. В таком случае приходится поднимать планку приемлемого риска и переносить центр тяжести на смягчение последствий и выработку планов восстановления после аварий, стихийных бедствий и иных происшествий. Продолжая пример с сейсмоопасностью, можно рекомендовать регулярное тиражирование данных в другой город и овладение средствами восстановления первичной базы данных.
Как и всякую иную деятельность, реализацию и проверку новых регуляторов безопасности следует предварительно распланировать. В плане необходимо учесть наличие финансовых средств, сроки обучения персонала. Нужно составить план автономного и комплексного тестирования, если речь идет о программно-техническом механизме защиты.
Когда намеченные меры приняты, необходимо проверить их действенность - убедиться, что остаточные риски стали приемлемыми. Если это на самом деле так, значит, все в порядке и можно спокойно намечать дату ближайшей переоценки. В противном случае придется проанализировать допущенные ошибки и немедленно провести повторный сеанс управления рисками.
Безопасность в жизненном цикле системы
Если синхронизировать программу безопасности нижнего уровня с жизненным циклом защищаемого сервиса, то можно добиться большего эффекта с меньшими затратами. Программисты знают, что добавить новую возможность к уже готовой системе на порядок труднее и дороже, чем изначально запроектировать и реализовать ее. То же справедливо и для информационной безопасности.
Поскольку здесь мы пытаемся встать на точку зрения заказчика, то и жизненный цикл сервиса будем трактовать соответствующим образом - выделим в нем следующие этапы:
- Инициация. На этом этапе выявляется необходимость в приобретении нового сервиса, документируется его предполагаемое назначение.
- Закупка. На этом этапе составляются спецификации, прорабатываются варианты закупки, выполняется собственно закупка.
- Установка. Сервис устанавливается, конфигурируется, тестируется и вводится в эксплуатацию.
- Эксплуатация. На этом этапе сервис не только работает и администрируется, но и подвергается модификациям.
- Выведение из эксплуатации. Происходит переход на новый сервис.
На этапе инициации оформляется понимание того, что необходимо приобрести новый или значительно модернизировать существующий сервис; выполняются прикидки, какими характеристиками и какой функциональностью он должен обладать; оцениваются финансовые и иные ограничения.
В плане безопасности важнейшим действием на этом этапе является оценка критичности как самого сервиса, так и информации, которая с его помощью будет обрабатываться. Необходимо сформулировать ответы на следующие вопросы:
- Какого рода информация предназначается для обслуживания новым сервисом?
- Каковы возможные последствия нарушения конфиденциальности, целостности и доступности этой информации?
- Каковы угрозы, по отношению к которым сервис и информация будут наиболее уязвимы?
- Существуют ли какие-либо особенности нового сервиса, требующие принятия специальных операционных мер, например, территориальная разнесенность компонентов?
- Каковы характеристики персонала, имеющие отношение к безопасности: квалификация, благонадежность?
- Каковы законодательные положения и внутренние правила, которым должен удовлетворять новый сервис?
Результаты оценки критичности являются отправной точкой в составлении спецификаций. Кроме того, они определяют ту меру внимания, которую служба безопасности организации должна уделять новому сервису на последующих этапах его жизненного цикла.
Этап закупки - один из самых сложных. Нужно окончательно сформулировать требования к защитным средствам нового сервиса, к компании, которая может претендовать на роль поставщика, и к квалификации персонала, использующего или обслуживающего закупаемый продукт. Все эти сведения оформляются в виде спецификации, куда входят не только аппаратура и программы, но и документация, послепродажное обслуживание, обучение персонала. Разумеется, особое внимание должно быть уделено вопросам совместимости нового сервиса с существующей конфигурацией. Подчеркнем также, что нередко средства безопасности являются необязательными компонентами коммерческих продуктов и нужно проследить, чтобы соответствующие пункты не выпали из спецификации.
Когда продукт закуплен, его необходимо установить. Несмотря на кажущуюся простоту, установка является очень ответственным делом. Можно провести аналогию с появлением ребенка в доме, когда требуется пересмотр многих сложившихся стереотипов.
Во-первых, новый продукт следует сконфигурировать. Как правило, коммерческие продукты поставляются с отключенными средствами безопасности; их необходимо включить и должным образом настроить. Для большой организации, где много пользователей и данных, начальная настройка часто может стать трудоемким и ответственным делом. Во-вторых, новый сервис нуждается в операционных регуляторах. Следует позаботиться о чистоте и охране помещения, о документах, регламентирующих использование сервиса, о подготовке планов на случай экстренных ситуаций, об организации обучения пользователей и т.п.
После принятия перечисленных мер необходимо провести тестирование. Его полнота и комплексность могут служить гарантией безопасности эксплуатации в штатном режиме.
Период эксплуатации - самый длительный и сложный. С психологической точки зрения наибольшую опасность в это время составляют небольшие изменения в конфигурации сервиса, в поведении пользователей и администраторов. Если безопасность не поддерживать, она имеет свойство ослабевать. Пользователи не столь ревностно выполняют должностные инструкции, администраторы с меньшей тщательностью анализируют регистрационную информацию. То один, то другой пользователь получает дополнительные привилегии. Кажется, что в сущности ничего не изменилось; на самом же деле от былой безопасности остались одни воспоминания.
Для борьбы с эффектом медленных изменений приходится прибегать к периодическим проверкам безопасности сервиса. Разумеется, после значительных модификаций подобные проверки являются обязательными.
При выведении из эксплуатации затрагиваются аппаратно-программные компоненты сервиса и обрабатываемые им данные. Аппаратура продается, утилизируется или выбрасывается. Только в специфических случаях необходимо заботиться о физическом разрушении аппаратных компонентов, хранящих конфиденциальную информацию. Программы, вероятно, просто стираются, если иное не предусмотрено лицензионным соглашением.
Наиболее тонким вопросом является выведение данных из эксплуатации. Обычно их переносят на другую систему, архивируют, выбрасывают или уничтожают. Если архивирование производится с намерением впоследствии прочитать данные в другом месте, следует позаботиться об аппаратно-программной совместимости средств чтения и записи. Информационные технологии развиваются очень быстро, и через несколько лет может просто не оказаться устройств, способных прочитать старый носитель. Если данные архивируются в зашифрованном виде, необходимо сохранить ключ и средства расшифровки. При архивировании и хранении архивной информации нельзя забывать о поддержании конфиденциальности данных.
Уничтожение информации называется санацией. Имеется три метода уничтожения: перезапись, размагничивание и разрушение носителя. Если речь идет о данных на магнитных носителях, то для санации вполне достаточно тройной перезаписи случайными последовательностями бит. После этого даже с помощью специальной аппаратуры прочитать первоначальную информацию невозможно.
АО "Инфосистемы Джет"
Литература
[1] Галатенко В., Информационная безопасность. "Открытые системы", # 4, # 5, # 6, 1995, # 1, 1996.
