ISO/EIC 17799:2000
10 Разработка и обслуживание систем
10.1 Требования к безопасности систем
Цель: Обеспечить наличие встроенных средств защиты в информационных системах.
Сюда входит инфраструктура, бизнес-приложения и приложения, разработанные пользователями. Разработка и внедрение бизнес-процесса для поддержки приложения или сервиса могут оказывать значительное влияние на безопасность. Перед тем, как приступать к разработке информационной системы, необходимо определить и согласовать требования к безопасности.
Все требования к безопасности, включая возможную необходимость средств аварийного восстановления, должны быть учтены в проекте на этапе определения требований и оценены, согласованы и задокументированы в составе общего процесса создания информационной системы.
10.1.1 Анализ и определение требований к безопасности
При описании требований организации к созданию новых систем или к усовершенствованию существующих необходимо учитывать потребность в средствах обеспечения безопасности. При создании подобных спецификаций следует рассмотреть возможность включения в систему автоматических средств управления и необходимость в дополнительных ручных средствах управления. Подобный подход следует применять и при оценке программных пакетов, которые предполагается использовать в деятельности организации. В случае необходимости руководство может принять решение воспользоваться продуктами, прошедшими независимую оценку и сертификацию.
Требования к безопасности и средства защиты должны соответствовать ценности используемых информационных ресурсов и потенциальному ущербу для организации в случае сбоя или нарушения безопасности. Основой для анализа требований к безопасности и выбору мер для поддержки безопасности является оценка рисков и управление рисками.
Средства, включенные в состав системы на этапе разработки, обычно оказываются значительно дешевле в реализации и поддержке, чем средства, включенные во время реализации или после нее.
10.2 Безопасность в прикладных системах
Цель: Предотвратить потери, модификацию и неправомерное использование пользовательских данных в прикладных системах.
В прикладные системы (в том числе и в приложения, разработанные пользователями) должны быть встроены необходимые средства защиты и функции ведения аудиторских записей или журналов операций. Эти средства должны обеспечивать проверку вводимых данных, внутренней обработки и результатов работы.
Для систем, которые обрабатывающих конфиденциальную, ценную и/или критичную информацию или оказывают определенное воздействие на такую информацию, могут потребоваться дополнительные средства защиты. Перечень необходимых средств следует определить на основе требований к безопасности и результатов оценки рисков.
68 |
© ISO/EIC 2000 |
|
© Перевод компании Информзащита 2004 |
ISO/EIC 17799:2000
10.2.1 Проверка вводимых данных
Данные, вводимые в прикладные системы, необходимо проверять, чтобы гарантировать их правильность и соответствие поставленной задаче. Проверку должны проходить исходные данные бизнес-транзакций, постоянные данные (имена и адреса, кредитные лимиты, контрольные номера заказчиков) и таблицы параметров (отпускные цены, курсы валют, суммы налогов). Рекомендуется рассмотреть следующие меры:
a)двукратный ввод или другой способ проверки ввода для обнаружения следующих ошибок:
1)значения, выходящие за допустимый диапазон;
2)недопустимые символы в полях данных;
3)отсутствующие или неполные данные;
4)превышение верхних и нижних пределов объема данных;
5)несанкционированные или несогласованные управляющие данные;
b)периодический просмотр содержимого ключевых полей и файлов данных для проверки их достоверности и целостности;
c)просмотр документов, введенных с печатных копий, на предмет несанкционированного изменения введенных данных (все изменения во вводимых документах должны санкционироваться);
d)правила реакции на ошибки при проверке;
e)процедуры проверки правдоподобности введенных данных;
f)определение обязанностей всех сотрудников, участвующих в процессе ввода данных.
10.2.2 Контроль обработки информации
10.2.2.1 Области риска
Данные, которые были введены правильно, могут быть повреждены в результате ошибок при обработке или злого умысла. Для обнаружения таких повреждений в систему должны быть встроены функции проверки. Структура приложений должна обеспечивать наличие ограничений, которые уменьшили бы риск ошибок обработки, приводящих к утрате целостности. Вот вопросы, которые следует рассмотреть:
a)использование и размещение в программах функций добавления и удаления данных для внесения изменений в данные;
b)процедуры, предотвращающие запуск программ в неправильном порядке или запуск после сбоя в предыдущей процедуре обработки (см. также раздел 8.1.1);
c)использование нужных программ для восстановления после сбоев, чтобы обеспечить правильную обработку данных.
10.2.2.2 Проверка и контроль
Перечень средств, которые необходимо реализовать, зависит от природы приложения и влияния, которое повреждение данных может оказать на деятельность организации. Ниже приведено несколько примеров проверок, которые необходимо реализовать:
a)средства проверки на уровне сеанса или пакета, позволяющие проверить баланс файлов данных после выполненной транзакции;
b)средства балансировки, обеспечивающие сравнения начального результата с предыдущим конечным результатом, а именно:
© ISO/EIC 2000, |
69 |
© Перевод компании Информзащита 2004 |
|
ISO/EIC 17799:2000
1)средства проверки при каждом проходе;
2)проверка итогов обновления файлов;
3)средства проверки результатов работы различных программ;
c)проверка правильности данных, сгенерированных системой (см. раздел 10.2.1);
d)проверка целостности программ и данных, передаваемых между центральным и удаленными компьютерами (см. раздел 10.3.3);
e)контрольные суммы записей и файлов;
f)проверка правильности времени запуска прикладных программ;
g)проверки, позволяющие убедиться в том, что программы запускаются в правильном порядке и прекращают работу в случае сбоев, а дальнейшая обработка не выполняется до тех пор, пока проблема не будет решена.
10.2.3Аутентификация сообщений
Аутентификация сообщений – это метод, позволяющий обнаружить несанкционированные изменения или повреждение содержимого передаваемых электронных сообщений. Этот метод может быть реализован либо на аппаратном, либо на программном уровне – с помощью физического устройства аутентификации или программного алгоритма.
Аутентификацию сообщений рекомендуется применять в тех областях, безопасность которых требует защиты целостности содержимого сообщения – например, электронное перечисление средств, передача характеристик, контрактов и предложений значительной важности, а также прочие подобные операции обмена электронными данными. Необходимо выполнить оценку рисков, чтобы установить, необходима ли аутентификация сообщений, и определить наиболее подходящий метод реализации.
Аутентификация сообщений не обеспечивает защиту содержимого сообщения от несанкционированного раскрытия. Для реализации аутентификации сообщений можно использовать криптографические методы (см. разделы 10.3.2 и 10.3.3).
10.2.4 Проверка результатов работы
Результаты работы, выдаваемые прикладной системой, необходимо проверять для того, чтобы убедиться, что сохраненная информация была обработана правильно и соответствует всем условиям. Как правило, при разработке систем предполагается, что при принятии соответствующих мер результаты проверки достоверности и тестирования выданных данных всегда будут положительными. Это не всегда так. Проверка результатов работы может включать:
a)проверку правдоподобия, позволяющую убедиться в осмысленности выданных данных;
b)подсчет контрольных сумм, позволяющий убедиться, что данные были обработаны полностью;
c)предоставление достаточного количества данных для того, чтобы читатели или последующие системы обработки смогли определить правильность, полноту, точность и классификацию информации;
d)правила реакции на ошибки при проверке результатов;
e)определение обязанностей всех сотрудников, участвующих в процессе вывода данных.
70 |
© ISO/EIC 2000 |
|
© Перевод компании Информзащита 2004 |