Здавалка
Главная | Обратная связь

Методология разработки



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

Определение требований

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

Разработка

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

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

Тестирование

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

Примечание

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

Реализация

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

Примечание

Методология разработки предназначена не только для внутренних разработок. Аналогичные шаги следует предпринимать и при работе с коммерческими проектами.

Планы восстановления после сбоев

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

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







©2015 arhivinfo.ru Все права принадлежат авторам размещенных материалов.