Политика

Процедура контроля над изменениями

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

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

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

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

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

Разработка

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

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

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

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

Примечание

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

Реализация

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

Примечание

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

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

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

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

Сбои отдельной системы или устройства

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

Совет

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

События, связанные с хранением данных

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

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

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

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

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

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

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

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

Вопросы для самопроверки

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