Управление информационной безопасностью. Стандарты СУИБ (СИ) - Вадим Викторович Гребенников Страница 19

Управление мощностью

Меры и средства

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

Рекомендации по реализации

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

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

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

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

Обеспечение достаточной мощности должно достигаться ее увеличением или снижением ее потребности. Примерами такого снижения могут быть:

— удаление устаревших данных (чистка диска);

— вывод из эксплуатации приложений, систем, баз данных;

— оптимизация групповых процессов и режимов;

— оптимизация логики приложения и запросов базы данных;

— запрет или ограничения трафика для ресурсоемкого сервиса, если он не критичен для бизнеса (например, потоковое видео).

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

Разделение сред разработки, тестирования и эксплуатации

Меры и средства

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

Рекомендации по реализации

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

Необходимо рассмотреть следующие вопросы:

— правила перевода ПО между состояниями разработки и эксплуатации должны быть определены и задокументированы;

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

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

— тестирование не должно проводиться в эксплуатируемых системах, кроме исключительных случаев;

— составители, редакторы и другие инструменты или системные программы разработки не должны быть доступны в эксплуатируемых системах без необходимости;

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

— критичные данные не должны копироваться в среду системы тестирования, пока не будут внедрены эквивалентные меры защиты в систему тестирования.

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

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

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

8.2. Контроль системного ПО

Цель: Обеспечить целостность операционных систем (далее — ОС).

Установка системного ПО

Меры и средства

Должны быть внедрены процедуры контроля установки системного ПО

Рекомендация по реализации

Для контроля изменений системного ПО необходимо рассмотреть следующие рекомендации:

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

— ОС должны содержать утвержденный исполняемый код и компиляторы;

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

— должна использоваться система контроля конфигурации для контроля всего внедренного ПО и системной документации;

— следует внедрить стратегию отката перед осуществлением изменений;

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

— предыдущие версии приложений ПО следует хранить на случай непредвиденных обстоятельств;

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

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

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

8.3. Защита от вредоносного ПО

Цель: Обеспечить защиту информации и средств ее обработки от вредоносного ПО.

Меры защиты от вредоносного ПО

Меры и средства

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

Рекомендации по реализации

Защита от вредоносного ПО должна базироваться на ПО его обнаружения и исправления, осведомленности в сфере ИБ и соответствующих средствах управления системным доступом и изменением. Необходимо рассмотреть следующие рекомендации:

— создание формальной политики запрета на использование неразрешенного ПО;

— внедрение средств обнаружения или предотвращения использования неразрешенного ПО (например, ведения «белого списка»);

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

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

— уменьшение уязвимостей, которые могут использоваться вредоносным ПО, например, с помощью управления техническими уязвимостями;

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

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

следует проводить сканирование на наличие вредоносного ПО перед использованием:

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

• электронных почтовых прикрепленных файлов и загрузок;

• веб-сайтов;

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

— подготовка соответствующиих планов по обеспечению непрерывности бизнеса в части восстановления после вредоносных атак, включая все необходимые меры по резервному копированию и восстановлению данных и ПО;

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

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

руководство