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

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

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

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

Конфиденциальные системы должны иметь выделенную (изолированную) вычислительную среду.

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

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

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

Рекомендация ITU-T X.1051. Разр. и тех. обсл. сист.: треб к без. сист.электросвязи, без. в прилож., крипт. средства упр.

( Разработка и техническое обслуживание системы: требования к безопасности систем электросвязи)

Цель: гарантировать, что средства обеспечения безопасности встроены в системы электросвязи.

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

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

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

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

( Разработка и техническое обслуживание системы: безопасность в приложениях)

Цель: предотвратить потери, несанкционированное изменение или неправильное использование данных в прикладных системах.

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

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

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

Проверка правильности выходных данных должна охватывать:

– проверки правдоподобности с целью определения обоснованности выходных данных;

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

– процедуры ответа на проверку правильности выходных данных.

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

Цель: защитить конфиденциальность, аутентичность или целостность информации.

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

При разработке политики должны рассматриваться следующие вопросы:

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

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

– роли и ответственность за реализацию криптографической политики;

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

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

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

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

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

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

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

Рекомендация ITU-T X.1051. Разр. и тех. обсл. сист.: безопасность системных файлов

(Разработка и техническое обслуживание системы: безопасность системных файлов)

Цель: для обеспечения безопасности доступ к системным файлам должен контролироваться.

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

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

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

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

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

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

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

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

– в программном обеспечении должны применяться "заплаты", если они могут помочь устранить или уменьшить слабые места безопасности.

Данные тестирования должны быть защищены и должны контролироваться.

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

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

– процедуры управления доступом, которые применяются к эксплуатационным прикладным системам, должны применяться также к тестовым прикладным системам;

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

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

Должен осуществляться строгий контроль доступа к библиотеке текстов программ.

Для уменьшения вероятности порчи компьютерных программ должны учитываться следующие требования к контролю доступа к библиотекам текстов программ:

– библиотеки текстов программ не должны храниться в эксплуатационных системах;

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

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

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

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

Рекомендация ITU-T X.1051. Разр. и тех. обсл. сист.: безоп. процессов разраб. и поддержки

(Разработка и техническое обслуживание системы: безопасность процессов разработки и поддержки)

Цель: поддержка безопасности программного обеспечения и информации прикладной системы.

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

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

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

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

Этот процесс должен содержать:

– необходимые изменения, представленные уполномоченными пользователями;

– проверку средств управления процедурами обеспечения целостности, чтобы убедиться, что они не скомпрометированы этими изменениями;

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

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

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

– гарантию того, что набор системной документации обновляется после завершения каждого изменения и что старая документация архивируется или уничтожается;

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

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

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

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

Этот процесс должен охватывать:

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

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

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

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

– лицензионные положения, право собственности на программу и права интеллектуальной собственности;

– сертификация качества и правильности выполненной работы;

– условное соглашение с третьей стороной на случай ошибки третьей стороны;

– права доступа для проверки качества и точности выполненной работы;

– договорные требования к качеству программы;

– тестирование перед установкой с целью выявления вредоносной программы.

Контрольные вопросы и задания

1. За обеспечение безопасности каждого коммутатора электросвязи отвечают специалисты по безопасности или линейные администраторы технического обслуживания сети? Где документируется подобное распределение обязанностей по безопасности?

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

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

4. Предложите возможные механизмы, способные оценивать стоимость инцидентов и нарушений.

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

6. Оцените, насколько это возможно, соответствие защищенности известных региональных «центров связи" описанным выше требованиям.

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

8. Какими могут быть возможные указания организации электросвязи, относительно возможности еды, питья и курения вблизи средств электросвязи?

9. Почему силовые кабели должны быть отделены от кабелей связи?

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

11. Правила "чистого стола/чистого экрана" в организации электросвязи должны использоваться в рабочее время, в нерабочее время или постоянно?

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

13. Зачем необходимо разделять экспериментальные, испытательные и эксплуатационные средства в организации электросвязи?

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

15. Какие защитные меры должны быть предусмотрены для защиты от атак "отказ в обслуживании" (DoS) на такие коммутационные средства, как маршрутизаторы?

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

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

18. Что понимается под управляемой реализацией при сопровождении введения новых систем и больших изменениях в существующих системах?

Вопрос 18: Основные понятия и идеи Общей методологии оценки безопасности ИТ. Входная и выходная задачи, задача оценки

подписали соглашение о признании сертификатов по ОК в области безопасности ОТ. Участие в соглашении предусматривает соблюдение 2 независимых условий:

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

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

соглашение предусматривает жёсткий контроль при получении и подтверждении этого права

Основная цель ОМО — добиться объективности, повторяемости ивоспроизводимости. В процессе оценки выделяются задачи:

· входная задача;

· задача оценки;

· выходная задача.

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

На всех этапах оценки должна обеспечиваться конфиденциальность.

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

· оценка ЗБ,

· оценка управления конфигурацией ОО,

· оценка документации по передаче ОО потребителю и эксплуатационная документация,

· оценка документации разработчиков,

· оценка руководств,

· оценка поддержки жизненного цикла объекта оценки,

· оценка тестов,

· оценка анализа уязвимостей.

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

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

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

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

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

ОМО предписывает следующую структуру подобных отчётов:

· введение;

· архитектурное (высокоуровневое описание объекта оценки с рассмотрением основных компонент);

· описание процесса оценки, применённых методов, методологический инструмент, средства и стандарты;

· представления результатов оценки, выводы и рекомендации;

· список представленных свидетельств;

· список сокращений, словарь терминов;

· словарь замечаний.

[1] Следует отметить, что требования ГОСТ Р ИСО/МЭК 15408 практически мало подходят для систем информационных технологий, а тем более для таких распределенных и сложных систем как сети электросвязи.