Разрабатывающий и тестирующий персонал также представляет угрозу для конфиденциальности эксплуатационной информации. Если действия по разработке и тестированию осуществляются в одной компьютерной среде, они могут привести к непредвиденным изменениям ПО или информации.
Поэтому разделение сред разработки, тестирования и эксплуатации целесообразно для снижения риска непредвиденного изменения или несанкционированного доступа к эксплуатационному ПО и бизнес-данным.
8.2. Контроль системного ПО
Цель: Обеспечить целостность операционных систем (далее — ОС).
Установка системного ПО
Меры и средства
Должны быть внедрены процедуры контроля установки системного ПО
Рекомендация по реализации
Для контроля изменений системного ПО необходимо рассмотреть следующие рекомендации:
— обновление ПО, приложений и программных библиотек ОС должны выполнять обученные администраторы, имеющие соответствующие полномочия от руководства;
— ОС должны содержать утвержденный исполняемый код и компиляторы;
— приложения и системное ПО следует внедрять только после всестороннего и успешного тестирования; тесты должны охватывать пригодность, безопасность, влияние на другие системы, удобство использования и проводиться на отдельных системах; все соответствующие библиотеки программных исходных кодов должны быть обновлены;
— должна использоваться система контроля конфигурации для контроля всего внедренного ПО и системной документации;
— следует внедрить стратегию отката перед осуществлением изменений;
— должен вестись журнал аудита всех обновлений используемых программных библиотек;
— предыдущие версии приложений ПО следует хранить на случай непредвиденных обстоятельств;
— старые версии ПО дожны архивироваться вместе со всей требуемой информацией о параметрах, процедурах, деталях конфигурации и поддерживающем ПО до окончания срока архивного хранения.
Поставляемое разработчиком системное ПО должно содержаться на том уровне, который поддерживает поставщик. Со временем разработчик ПО перестает поддерживать его старейшие версии. Организации следует рассмотреть риски использования неподдерживаемого ПО.
Любое решение о переходе на новую версию ПО надо принимать с учетом бизнес-требований для изменения и безопасности версии, например, появление в связи с этим новой функциональности ИБ или каких-то серьезных проблем ИБ. Исправления ПО надо применять тогда, когда они могут устранить или уменьшить недостатки ИБ.
8.3. Защита от вредоносного ПО
Цель: Обеспечить защиту информации и средств ее обработки от вредоносного ПО.
Меры защиты от вредоносного ПО
Меры и средства
Должны быть внедрены меры обнаружения, предотвращения и исправления для защиты от вредоносного ПО совместно с осведомленностью пользователей.
Рекомендации по реализации
Защита от вредоносного ПО должна базироваться на ПО его обнаружения и исправления, осведомленности в сфере ИБ и соответствующих средствах управления системным доступом и изменением. Необходимо рассмотреть следующие рекомендации:
— создание формальной политики запрета на использование неразрешенного ПО;
— внедрение средств обнаружения или предотвращения использования неразрешенного ПО (например, ведения «белого списка»);
— внедрение средств обнаружения или предотвращения использования известных и подозреваемых вредоносных сайтов (например, ведения «черного списка»);
— создание формальной политики защиты от рисков, связанных с получением файлов и ПО с помощью внешних сетей или других носителей, показывающей, какие меры защиты следует принять;
— уменьшение уязвимостей, которые могут использоваться вредоносным ПО, например, с помощью управления техническими уязвимостями;
— проведение регулярных пересмотров ПО и содержания системных данных, поддерживающих критичные бизнес-процессы; необходимо формальное расследование наличия любых неразрешенных файлов или несанкционированных изменений;
— установка и регулярное обновление ПО обнаружения и исправления вредоносного ПО по сканированию компьютеров и носителей информации в качестве меры предосторожности или на регулярной основе;
следует проводить сканирование на наличие вредоносного ПО перед использованием:
• любых файлов, полученных с помощью сетей или других носителей;
• электронных почтовых прикрепленных файлов и загрузок;
• веб-сайтов;
— определение процедур и обязанностей по защите от вредоносного ПО в системах, обучение их использованию, оповещение и восстановление после вредоносных атак;
— подготовка соответствующиих планов по обеспечению непрерывности бизнеса в части восстановления после вредоносных атак, включая все необходимые меры по резервному копированию и восстановлению данных и ПО;
— внедрение процедур регулярного сбора информации, таких как подписка на почтовые рассылки или проверка веб-сайтов, предоставляющих информацию о новом вредоносном ПО;
— внедрение процедур проверки информации, касающейся вредоносного ПО, и обеспечение точности и информативности предупредительных бюллетней;
руководство должно быть уверено, что для разделения фальшивого и реального ПО используются квалифицированные источники, например, авторитетные журналы, Интернет-сайты или поставщики, создающие ПО по защите от вредоносного ПО;
все пользователи должны быть осведомлены о фальшивках и действиях при их получении;
— изоляция от окружающей среды реального катастрофического влияния.
8.4. Резервировное копирование
Цель: Обеспечить защиту от потери данных.
Резервируемая информация
Меры и средства
Резервные копии информации, ПО и образов систем должны создаваться и регулярно тестироваться в соответствии с утвержденной политикой резервного копирования.
Рекомендация по реализации
Политика резервного копирования должна быть установлена для определения требований организации по резервному копированию информации, ПО и систем. Политика должна определить требования по хранению и защите.
Адекватные средства резервного копирования должны обеспечить восстановление всей важной информации и ПО после разрушения или повреждения носителей.
При составлении плана резервного копирования необходимо рассмотреть следующие вопросы:
— обеспечение точных и полных записей резервных копий и документирование процедур восстановления;
— объем (полное или выборочное) и частота резервного копирования должны отражать требования бизнеса организации, безопасности связанной информации и критичность информации для непрерывности бизнеса;
— хранение резервных копий в удаленном месте, на надежном расстоянии, достаточном, чтобы избежать любого повреждения из-за разрушения в основном месте;
— обеспечение соответствующего уровня физической и экологической защиты резервируемой информации в соответствии со стандартами, применяемыми в основном месте;
— регулярное тестирование носителей резервируемой информации для обеспечения, при необходимости, их аварийного использования, которое надо объединять с тестом процедур восстановления и проверкой в отношении требуемого времени восстановления;
тестирование способности восстановления данных должно осуществляться на выделенных для этой цели носителях, не перезаписывая исходных носителей на случай нарушения процесса резервного копирования или восстановления и причинения непоправимого повреждения или потери данных;
— в ситуациях, когда конфиденциальность играет важную роль, резервные копии необходимо защищать шифрованием.
Операционные процедуры должны контролировать уничтожение резервных копий и выполнение планового резервного копирования для обеспечения его полноты в соответствии с политикой резервного копирования.
Меры резервного копирования индивидуальных систем и сервисов должны регулярно тестироваться на предмет соответствия требованиям планов непрерывности бизнеса. Для критичных систем и сервисов меры резервного копирования должны охватытвать всю системную информацию, приложения и данные, необходимые для полного восстановления системы на случай разрушения.
8.5. Протоколирование и мониторинг
Цель: Записывать события и получать фактические данные.
Протоколирование и мониторинг обеспечивают следующие мероприятия:
— протоколирование событий;
— защита логов;
— ведение логов пользователей;
— синхронизация часов.
Протоколирование событий
Меры и средства
Журналы (логи) событий, в которые записываются действия пользователей, ошибки и события ИБ, должны вестить, сохраняться и регулярно пересматриваться.
Рекомендации по реализации
Логи должны включать, при необходимости:
— идентификаторы пользователей;
— системные действия;
— даты, время и детали ключевых событий, например начало и завершение сеанса;
— идентичность и местоположение устройства, по возможности, и идентификатор системы;
— регистрацию успешных и отклоненных попыток доступа к системе;
— регистрацию успешных и отклоненных попыток доступа к данным или другим ресурсам;
— изменения конфигурации системы;
— использование привилегий;
— использование системного и прикладного ПО;
— файлы, к которым был получен доступ, и вид доступа;
— сетевые адреса и протоколы;
— сигналы тревоги системы управления доступом;
— активация и деактивация систем защиты, таких как антивирусы и системы обнаружения вторжения;
— запись операций, сделанных пользователем в приложениях.
Протоколирование событий является фундаментом для автоматических систем мониторинга, создающих объединенные отчеты и сигналы безопасности системы.
Логи событий могут содержать критичную информацию и персональные данные, поэтому должны быть на