Управление информационной безопасностью

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

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

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

       контроль за выполнением операций;

       подведение итогов по обновлению файлов;

       контроль за выполнением программ;

в) проверка достоверности данных, сгенерированных системой (см. Проверка достоверности входных данных);

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

д) подведение итогов по обновлению файлов.

Шифрование данных

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

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

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

Аутентификация сообщений

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

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

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

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

Защита файлов прикладных систем

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

Доступ к системным файлам необходимо контролировать.

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

Контроль рабочего программного обеспечения

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

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

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

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

г) Необходимо фиксировать все случаи обновления рабочих библиотек программ в контрольном журнале.

д) Предыдущие версии программ следует сохранить — мера предосторожности при чрезвычайных ситуациях.

Защита системных тестовых данных

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

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

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

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

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

Безопасность в среде разработки и рабочей среде

Цель: Обеспечить защиту прикладного программного обеспечения и данных.

Среду разработки и рабочую среду необходимо жестко контролировать.

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

Процедуры управления процессом внесения изменений

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

а) регистрацию согласованных уровней полномочий, в том числе:

       служба приема запросов на внесение изменений группой, обслуживающей информационные системы;

       полномочия пользователей на подачу запросов на внесение изменений;

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

       полномочия пользователей на принятие вносимых изменений;

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

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

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

д) утверждение подробных предложений до начала работы;

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

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

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

и) регистрацию всех запросов на внесение изменений в контрольном журнале.

Технический анализ изменений, вносимых в операционную систему

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

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

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

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

Ограничения на внесение изменений в пакеты программ

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

а) риск компрометации встроенных средств контроля и процессов обеспечения целостности;

б) необходимость получения согласия поставщика;

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

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

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

Раздел 9 Планирование бесперебойной работы организации

Вопросы планирования бесперебойной работы организации

Цель: Составить планы для предотвращение перебоев в работе организации.

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

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

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

Процесс планирования бесперебойной работы организации

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

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

а) идентификацию критически важных производственных процессов и их ранжирование по приоритетам;

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

в) определение и согласование всех обязанностей и планов действий в чрезвычайных ситуациях;

г) документирование согласованных процедур и процессов;

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

е) тестирование планов;

ж) пересмотр и обновление планов.

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

Система планирования бесперебойной работы организации

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

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

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

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

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

г) график испытаний, который определяет, как и когда будет проведено тестирование плана.

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