Текст книги "Управление информационной безопасностью. Стандарты СУИБ (СИ)"

Автор книги: Вадим Гребенников

сообщить о нарушении

Текущая страница: 7 (всего у книги 18 страниц) [доступный отрывок для чтения: 7 страниц]

8. Безопасность операций

Безопасность операций определяют следующие составляющие:

– операционные процедуры;

– контроль системного ПО;

– защита от вредоносного ПО;

– мониторинг и логи.

– резервное копирование;

– управление техническими уязвимостями;

– проведение аудита ИС.

8.1. Операционные процедуры

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

Операционные процедуры обеспечивают следующие мероприятия:

– документирование процедур;

– управление изменениями;

– управление мощностью;

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

Документирование процедур

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

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

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

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

Операционные процедуры должны определять эксплуатационные инструкции, включающие:

– инсталляцию и конфигурацию систем;

– обработку и управление информацией, как автоматизированное, так и ручное;

– резервное копирование;

– требования в отношении графика работ, включая взаимозависимости с другими системами, время начала первой и время завершения последней процедуры;

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

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

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

– перезапуск системы и процедуры восстановления на случай системного сбоя;

– управление информацией, содержащейся в контрольных и системных журналах;

– процедуры мониторинга.

Управление изменениями

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

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

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

В частности, необходимо рассмотреть следующие аспекты:

– определение и регистрацию существенных изменений;

– планирование и тестирование изменений;

– оценку возможных влияний таких изменений, включая влияния на ИБ;

– формальную процедуру утверждения предлагаемых изменений;

– проверку соответствия требованиям ИБ;

– подробное информирование об изменениях всех заинтересованных лиц;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– изоляция от окружающей среды реального катастрофического влияния.

8.4. Резервировное копирование

Цель: Обеспечить защиту от потери данных.

Резервируемая информация

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

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

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

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

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

При составлении плана резервного копирования необходимо рассмотреть следующие вопросы:

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

– объем (полное или выборочное) и частота резервного копирования должны отражать требования бизнеса организации, безопасности связанной информации и критичность информации для непрерывности бизнеса;

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

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

– регулярное тестирование носителей резервируемой информации для обеспечения, при необходимости, их аварийного использования, которое надо объединять с тестом процедур восстановления и проверкой в отношении требуемого времени восстановления;

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

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

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

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

8.5. Протоколирование и мониторинг

Цель: Записывать события и получать фактические данные.

Протоколирование и мониторинг обеспечивают следующие мероприятия:

– протоколирование событий;

– защита логов;

– ведение логов пользователей;

– синхронизация часов.

Протоколирование событий

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

Журналы (логи) событий, в которые записываются действия пользователей, ошибки и события ИБ, должны вестить, сохраняться и регулярно пересматриваться.

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

Логи должны включать, при необходимости:

– идентификаторы пользователей;

– системные действия;

– даты, время и детали ключевых событий, например начало и завершение сеанса;

– идентичность и местоположение устройства, по возможности, и идентификатор системы;

– регистрацию успешных и отклоненных попыток доступа к системе;

– регистрацию успешных и отклоненных попыток доступа к данным или другим ресурсам;

– изменения конфигурации системы;

– использование привилегий;

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

– файлы, к которым был получен доступ, и вид доступа;

– сетевые адреса и протоколы;

– сигналы тревоги системы управления доступом;

– активация и деактивация систем защиты, таких как антивирусы и системы обнаружения вторжения;

– запись операций, сделанных пользователем в приложениях.

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

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

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

Защита логов

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

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

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

Меры защиты направлены на предотвращение несанкционированных изменений в логах и эксплуатационных проблем со средствами протоколирования, включающих:

– изменения типов записываемых сообщений;

– редактирование или удаление файлов логов;

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

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

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

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

Логи пользователя

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

Действия пользователей (администраторов) системы должны протоколироваться, и логи сохраняться и регулярно пересматриваться.

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

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

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

Синхронизация часов

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

Часы всех систем обработки информации внутри организации или домена безопасности должны быть синхронизированы с единым эталонным источником времени.

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

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

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

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

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

8.6. Управление техническими уязвимостями

Цель: Предотвратить использование технических уязвимостей.

Управление техническими уязвимостями обеспечивают следующие мероприятия:

– обработка технических уязвимостей;

– ограничение на установку ПО.

Обработка технических уязвимостей

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

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

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

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

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

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

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

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

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

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

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

– при наличии возможности установки легального патча следует оценить риски, связанные с его установкой (риски от уязвимости сравнить с риском установки патча);

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

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

• адаптирование или добавление средств контроля доступа, например, сетевые экраны или границы;

• расширенный мониторинг для выявления актуальных атак;

• повышение осведомленности об уязвимости;

– следует вести журнал аудита для всех предпринятых процедур;

– следует регулярно проводить мониторинг и оценку процесса управления техническими уязвимостями на предмет его эффективности и действенности;

– в первую очередь надо обращать внимание на системы с высоким уровнем риска;

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

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

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

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

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

Ограничение на установку ПО

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

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

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

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

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

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

8.7. Проведение аудита ИС

Цель: Минимизировать влияние аудиторских действий на действующие системы.

Контроль аудита систем

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

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

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

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

– аудиторские требования в отношении доступа к системам и данным следует согласовать|согласиться| с соответствующим руководством;

– контекст технических аудиторских тестов следует согласовать|согласиться| и контролировать|управлять, контролировать|;

– аудиторские тесты должны| иметь ограничение доступа к ПО и данным в виде «только для чтения»;

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

– требования специальной или дополнительной|аддиционной| обработки следует определить|опознать| и согласовать|согласиться|;

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

– все факты доступа|подход, припадок, прирост, приступ, проход| нужно контролировать и протоколировать, чтобы остался документальный след|хвост|.

От автора

В 1969 году была основана Ассоциация аудита и контроля ИС «ISACA» (Information System Audit and Control Association), которая в настоящее время объединяет около 20 тысяч членов из более чем 100 стран. Ассоциация координирует деятельность более чем 12 тысяч аудиторов ИС. Официальный сайт: www.isaca.org.

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

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

«CoBiT» (Control оbjectives for information and related technologies – Контрольные объекты информационных и смежных технологий) – это открытый стандарт, первое издание которого в 1996 году было продано в 98 странах по всему миру и облегчило работу профессиональных аудиторов в сфере информационных технологий.

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

Основополагающее правило, положенное в основу «CoBiT»: ресурсы ИС должны управляться набором естественно сгруппированных процессов для обеспечения организации необходимой и надежной информацией. Версию 4.1 стандарта на украинском языке можно скачать на сайте «ISACA».