"ИНФОРМАЦИОННАЯ ТЕХНОЛОГИЯ. ПРАКТИЧЕСКИЕ ПРАВИЛА УПРАВЛЕНИЯ ИНФОРМАЦИОННОЙ БЕЗОПАСНОСТЬЮ. ГОСТ Р ИСО/МЭК 17799-2005"(утв. Приказом Ростехрегулирования от 29.12.2005 N 447-ст)

10. Разработка и обслуживание систем

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

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

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

10.1.1. Анализ и спецификация требований безопасности

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

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

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

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

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

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

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

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

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

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

1) значений, выходящих за допустимый диапазон;

2) недопустимых символов в полях данных;

3) отсутствующие или неполные данные;

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

5) неавторизованные или противоречивые контрольные данные;

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

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

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

д) процедуры проверки правдоподобия вводимых данных;

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

10.2.2. Контроль обработки данных в системе

10.2.2.1. Области риска

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

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

- процедуры для предотвращения выполнения программ в неправильной последовательности или ее исполнения после сбоя на предыдущем этапе обработки данных (8.1.1);

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

10.2.2.2. Проверки и средства контроля

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

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

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

1) средства контроля "от выполнения - к выполнению";

2) общие суммы измененных данных в файле;

3) средства контроля "от программы - к программе";

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

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

д) контрольные суммы записей и файлов;

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

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

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

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

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

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

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

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

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

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

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

- процедуры по выполнению тестов на подтверждение выводимых данных;

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

10.3. Меры защиты информации, связанные с использованием криптографии

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

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

10.3.1. Политика в отношении использования криптографии

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

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

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

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

в) роли и обязанности должностных лиц за:

1) реализацию политики;

2) управление ключами;

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

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

10.3.2. Шифрование

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

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

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

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

10.3.3. Цифровые подписи

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

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

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

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

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

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

10.3.4. Сервисы неоспоримости

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

10.3.5. Управление ключами

10.3.5.1. Защита криптографических ключей

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

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

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

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

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

10.3.5.2. Способы, процедуры и методы защиты криптографических ключей

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

- генерации ключей при использовании различных криптографических систем и различных приложений;

- генерации и получения сертификатов открытых ключей;

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

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

- смены или обновления ключей, включая правила порядка и сроков смены ключей;

- порядка действий в отношении скомпрометированных ключей;

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

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

- архивирования ключей, например для архивированной или резервной информации;

- разрушения ключей;

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

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

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

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

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

10.4. Безопасность системных файлов

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

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

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

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

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

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

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

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

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

- предыдущие версии программного обеспечения следует сохранять для восстановления системы в случае непредвиденных обстоятельств.

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

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

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

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

- процедуры контроля доступа, применяемые для прикладных систем, находящихся в промышленной эксплуатации, следует также применять и к прикладным системам в среде тестирования;

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

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

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

10.4.3. Контроль доступа к библиотекам исходных текстов программ

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

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

- назначать специалиста - библиотекаря программ для каждого бизнес-приложения;

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

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

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

- листинги программ следует хранить в безопасном месте (8.6.4);

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

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

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

10.5. Безопасность в процессах разработки и поддержки

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

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

10.5.1. Процедуры контроля изменений

Чтобы свести к минимуму повреждения информационных систем, следует строго контролировать внедрение изменений - строго придерживаться формализованных процедур обеспечения информационной безопасности; осуществлять контроль за возможной компрометацией самих процедур; программистам, отвечающим за поддержку, предоставлять доступ только к тем частям системы, которые необходимы для их работы; обеспечивать формализацию и одобрение соответствующим руководством всех изменений. Изменения в прикладном программном обеспечении могут повлиять на информационную безопасность используемых бизнес-приложений. Там, где это возможно, следует объединять меры по обеспечению информационной безопасности используемых бизнес-приложений и изменений в прикладных программах (3.1.2). Необходимо, чтобы этот процесс включал:

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

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

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

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

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

- разрешение внесения изменений в прикладные программы авторизованным пользователем до их непосредственной реализации;

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

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

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

- регистрацию в журналах аудита всех запросов на изменение;

- коррекцию эксплуатационной документации (8.1.1) и пользовательских процедур в соответствии с внесенными изменениями;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

10.5.4. Скрытые каналы утечки данных и "троянские" программы

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

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

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

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

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

- осуществлять контроль доступа к установленным программам и их модификациям;

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

10.5.5. Разработка программного обеспечения с привлечением сторонних организаций

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

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

- сертификацию качества и правильности выполненных работ;

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

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

- документирование требований к качеству программ в договорной форме;

- тестирование перед установкой программ на предмет обнаружения "Троянского коня".