Интеллектуальные компьютерные технологии защиты информации

• учитывала все аспекты безопасности системы;

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

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

• уделяла основное внимание областям риска и отчетности (например, сообщениям об искл

ючительных ситуациях);

• отслеживала свою собственную эффективность (т.е. регистрировала свои собственные удачи и сбои).

Распределить персональную ответственность за слежение за состоянием безопасности и определить конкретное время для этого.

Документировать процедуры и сферы ответственности.

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

3.8 Планирование мероприятий на случай выхода системы из строя

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

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

Вообще говоря, сбой является результатом:

1)проблемы в самой системе;

2)проблемы, являющейся внешней по отношению к системе, но локализованной (например, сбой питания или пожар в компьютерном зале);

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

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

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

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

3.8.1 Потенциальные угрозы

Потеря конфиденциальности вследствие:

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

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

Потеря целостности и/или доступности вследствие:

• случайной или умышленной потери или разрушения данных;

• потери или разрушения системного или прикладного программного обеспечения;

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

• выхода из строя сети или каналов связи;

• внешних факторов (например, пожара, пропадания питания, бомбового удара).

3.8.2 Пути снижения рисков

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

Разработать и внедрить процедуры восстановления (например, от «дисков с зеркальным отображением» до полного «горячего резерва»), которые могут определить:

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

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

• различные типы сбоев и их продолжительность;

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

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

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

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

• обеспечить совместимость резервных копий данных и систем;

• если система должна быть восстановлена в другом месте, проверить на совместимость систему и восстановительные программные средства;

• регулярно тестировать планы восстановления;

• проверять ранее сделанные резервные копии на читаемость;

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

• регистрировать местонахождение, состояние и «возраст» всех резервных копий (и хранить копию в удаленном месте);

• регулярно пересматривать все процедуры резервирования и восстановления.

3.9 Использование средств удаленной диагностики

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

 Скачать реферат