СРЕДСТВА ЗАЩИТЫ ИНФОРМАЦИИ

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

8.1. Анализ и задание требований к безопасности

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

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

Основу анализа требований к безопасности составляют:

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

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

В частности, при проведении такого анализа следует рассмотреть необходимость:

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

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

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

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

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

е) снятия резервных копий с критически важных производственных данных;

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

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

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

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

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

8.2. Безопасность в прикладных системах

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

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

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

8.3 Проверка достоверности входных данных.

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

а) проверки с целью выявления следующих ошибок:

· величины, выходящие за заданные пределы;

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

· пропущенные или неполные данные;

· превышенные верхние и нижние пределы на объем вводимых данных;

· несанкционированные или противоречивые управляющие данные;

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

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

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

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

8.4. Проверка достоверности внутренней обработки данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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