10.5 Безопасность в процессах разработки и поддержки

 
 Цель: поддержание безопасности прикладных систем и информации.
 
 Менеджеры, ответственные за прикладные системы, должны быть ответственными и за безопасность среды проектирования или поддержки. Они должны проводить анализ всех предложенных изменений системы и исключать возможность компрометации безопасности как системы, так и среды промышленной эксплуатации.
 
 10.5.1 Процедуры контроля изменений
 
 Чтобы свести к минимуму повреждения информационных систем, следует строго контролировать внедрение изменений - строго придерживаться формализованных процедур обеспечения информационной безопасности; осуществлять контроль за возможной компрометацией самих процедур; программистам, отвечающим за поддержку, предоставлять доступ только к тем частям системы, которые необходимы для их работы; обеспечивать формализацию и одобрение соответствующим руководством всех изменений. Изменения в прикладном программном обеспечении могут повлиять на информационную безопасность используемых бизнес-приложений. Там, где это возможно, следует объединять меры по обеспечению информационной безопасности используемых бизнес-приложений и изменений в прикладных программах (3.1.2). Необходимо, чтобы этот процесс включал:
 
 - обеспечение протоколирования согласованных уровней авторизации;
 
 - обеспечение уверенности в том, что запросы на изменения исходят от авторизованных соответствующим образом пользователей;
 
 - анализ мер информационной безопасности и процедур, обеспечивающих целостность используемых систем;
 
 - идентификацию всего программного обеспечения, информации, объектов, баз данных и аппаратных средств, требующих изменений;
 
 - получение формализованного одобрения детальных запросов/предложений на изменения перед началом работы;
 
 - разрешение внесения изменений в прикладные программы авторизованным пользователем до их непосредственной реализации;
 
 - осуществление процесса внедрения изменений в прикладные программы с минимальными отрицательными последствиями для бизнеса;
 
 - обеспечение обновления комплекта системной документации после завершения каждого изменения и архивирование или утилизация старой документации;
 
 - поддержку контроля версий для всех обновлений программного обеспечения;
 
 - регистрацию в журналах аудита всех запросов на изменение;
 
 - коррекцию эксплуатационной документации (8.1.1) и пользовательских процедур в соответствии с внесенными изменениями;
 
 - осуществление процесса внедрения изменений в согласованное время без нарушения затрагиваемых бизнес-процессов.
 
 Во многих организациях используется среда, в которой пользователи тестируют новое программное обеспечение и которая отделена от среды разработки и среды промышленной эксплуатации. При этом обеспечивается возможность контроля нового программного обеспечения и дополнительная защита операционной информации, используемой в процессе тестирования.
 
 10.5.2 Технический анализ изменений в операционных системах
 
 Периодически возникает необходимость внести изменения в операционные системы, например, установить последнюю поддерживаемую версию программного обеспечения. В этих случаях необходимо провести анализ и протестировать прикладные системы с целью обеспечения уверенности в том, что не оказывается никакого неблагоприятного воздействия на их функционирование и безопасность. Необходимо, чтобы этот процесс учитывал:
 
 - анализ средств контроля бизнес-приложений и процедур целостности, чтобы обеспечивать уверенность в том, что они не были скомпрометированы изменениями в операционной системе;
 
 - обеспечение уверенности в том, что ежегодный план поддержки и бюджет предусматривает анализ и тестирование систем, которые необходимо осуществлять при изменениях в операционной системе;
 
 - обеспечение своевременного поступления уведомлений об изменениях в операционной системе для возможности проведения соответствующего анализа их влияния на информационную безопасность перед установкой изменений в операционную систему;
 
 - контроль документирования соответствующих изменений в планах обеспечения непрерывности бизнеса (раздел 11).
 
 10.5.3 Ограничения на внесение изменений в пакеты программ
 
 Модификаций пакетов программ следует избегать. Насколько это возможно и допустимо с практической точки зрения, поставляемые поставщиком пакеты программ следует использовать без внесения изменений. Там, где все-таки необходимо вносить изменения в пакет программ, следует учитывать:
 
 - риск компрометации встроенных средств контроля и процесса обеспечения целостности;
 
 - необходимость получения согласия поставщика;
 
 - возможность получения требуемых изменений от поставщика в виде стандартного обновления программ;
 
 - необходимость разработки дополнительных мер поддержки программного обеспечения, если организация в результате внесенных изменений станет ответственной за будущее сопровождение программного обеспечения.
 
 В случае существенных изменений оригинальное программное обеспечение следует сохранять, а изменения следует вносить в четко идентифицированную копию. Все изменения необходимо полностью тестировать и документировать таким образом, чтобы их можно было повторно использовать, при необходимости, для будущих обновлений программного обеспечения.
 
 10.5.4 Скрытые каналы утечки данных и "троянские" программы
 
 Раскрытие информации через скрытые каналы может происходить косвенными и неавторизованными способами. Этот процесс может быть результатом активации изменений параметров доступа как к защищенным, так и к незащищенным элементам информационной системы, или посредством вложения информации в поток данных. "Троянские" программы предназначены для того, чтобы воздействовать на систему неавторизованным и незаметным способом, при этом данное воздействие осуществляется как на получателя данных, так и на пользователя программы. Скрытые каналы утечки и "троянские" программы редко возникают случайно. Там, где скрытые каналы или "троянские" программы являются проблемой, необходимо применять следующие мероприятия по обеспечению информационной безопасности:
 
 - закупку программного обеспечения осуществлять только у доверенного источника;
 
 - по возможности закупать программы в виде исходных текстов с целью их проверки;
 
 - использовать программное обеспечение, прошедшее оценку на соответствие требованиям информационной безопасности;
 
 - осуществлять проверку исходных текстов программ перед их эксплуатационным применением;
 
 - осуществлять контроль доступа к установленным программам и их модификациям;
 
 - использование проверенных сотрудников для работы с ключевыми системами.
 
 10.5.5 Разработка программного обеспечения с привлечением сторонних организаций
 
 В случаях, когда для разработки программного обеспечения привлекается сторонняя организация, необходимо применять следующие меры обеспечения информационной безопасности:
 
 - контроль наличия лицензионных соглашений и определенности в вопросах собственности на программы и соблюдения прав интеллектуальной собственности (12.1.2);
 
 - сертификацию качества и правильности выполненных работ;
 
 - заключение "escrow" соглашения, предусматривающих депонирование исходного текста на случай невозможности третьей стороны выполнять свои обязательства;
 
 - обеспечение прав доступа для аудита с целью проверки качества и точности выполненной работы;
 
 - документирование требований к качеству программ в договорной форме;
 
 - тестирование перед установкой программ на предмет обнаружения "Троянского коня".
 
 

 11 Управление непрерывностью бизнеса
 

 11.1 Вопросы управления непрерывностью бизнеса

 
 Цель: противодействие прерываниям бизнеса и защита критических бизнес-процессов от последствий при значительных сбоях или бедствиях.
 
 Необходимо обеспечивать управление непрерывностью бизнеса с целью минимизации отрицательных последствий, вызванных бедствиями и нарушениями безопасности (которые могут быть результатом природных бедствий, несчастных случаев, отказов оборудования и преднамеренных действий), до приемлемого уровня с помощью комбинирования профилактических и восстановительных мероприятий по управлению информационной безопасностью.
 
 Последствия от бедствий, нарушений безопасности и отказов в обслуживании необходимо анализировать. Необходимо разрабатывать и внедрять планы обеспечения непрерывности бизнеса с целью восстановления бизнес-процессов в течение требуемого времени при их нарушении. Такие планы следует поддерживать и применять на практике, чтобы они стали составной частью всех процессов управления.
 
 Необходимо, чтобы управление непрерывностью бизнеса включало мероприятия по управлению информационной безопасностью для идентификации и уменьшения рисков, ограничения последствий разрушительных инцидентов и обеспечения своевременного возобновления наиболее существенных бизнес-операций.
 
 11.1.1 Процесс управления непрерывностью бизнеса
 
 Необходимо, чтобы существовал управляемый процесс развития и поддержания непрерывности бизнеса для всей организации. Этот процесс должен объединять ключевые элементы управления непрерывностью бизнеса:
 
 - понимание рисков, с которыми сталкивается организация, с точки зрения вероятности возникновения и последствий, включая идентификацию и определение приоритетов критических бизнес-процессов;
 
 - понимание возможных последствий нарушения бизнес-процессов в случае незначительных или существенных инцидентов, потенциально угрожающих жизнедеятельности организации, а также выбора средств и способов обработки информации, которые соответствовали бы целям бизнеса;
 
 - организацию оптимального страхования результатов обработки информации, которое должно быть частью процесса обеспечения непрерывности бизнеса;
 
 - формулирование и документирование стратегии непрерывности бизнеса в соответствии с согласованными бизнес-целями и приоритетами;
 
 - формулирование и документирование планов обеспечения непрерывности бизнеса в соответствии с согласованной стратегией;
 
 - регулярное тестирование и обновление планов развития информационных технологий и существующих процессов;
 
 - обеспечение органичного включения в процессы и структуру организации планов управления непрерывностью бизнеса. Ответственность за координацию процесса управления непрерывностью бизнеса следует возлагать на орган, обладающий соответствующими полномочиями в организации, например на управляющий совет по информационной безопасности (4.1.1).
 
 11.1.2 Непрерывность бизнеса и анализ последствий
 
 Необходимо, чтобы планирование непрерывности бизнеса начиналось с идентификации событий, которые могут быть причиной прерывания бизнес-процессов, например отказ оборудования, наводнение или пожар. Планирование должно сопровождаться оценкой рисков с целью определения последствий этих прерываний (как с точки зрения масштаба повреждения, так и периода восстановления). Оценку рисков необходимо осуществлять при непосредственном участии владельцев бизнес-ресурсов и участников бизнес-процессов. Оценка риска должна распространяться на все бизнес-процессы и не ограничиваться только средствами обработки информации.
 
 В зависимости от результатов оценки рисков необходимо разработать стратегию для определения общего подхода к обеспечению непрерывности бизнеса. Разработанный план должен быть утвержден руководством организации.
 
 11.1.3 Разработка и внедрение планов обеспечения непрерывности бизнеса
 
 Следует разрабатывать планы по поддержке или восстановлению бизнес-операций в требуемые периоды времени после прерывания или отказа критических бизнес-процессов. Необходимо, чтобы план обеспечения непрерывности бизнеса предусматривал следующие мероприятия по обеспечению информационной безопасности:
 
 - определение и согласование всех обязанностей должностных лиц и процедур на случай чрезвычайных ситуаций;
 
 - внедрение в случае чрезвычайных ситуаций процедур, обеспечивающих возможность восстановления бизнес-процессов в течение требуемого времени. Особое внимание следует уделять оценке зависимости бизнеса от внешних факторов и существующих контрактов;
 
 - документирование согласованных процедур и процессов;
 
 - соответствующее обучение сотрудников действиям при возникновении чрезвычайных ситуаций, включая кризисное управление;
 
 - тестирование и обновление планов обеспечения непрерывности бизнеса.
 
 Необходимо, чтобы план обеспечения непрерывности бизнеса соответствовал требуемым целям бизнеса, например восстановлению определенных сервисов для клиентов за приемлемый промежуток времени. Следует учитывать потребности в необходимых для этого сервиса ресурсов, включая укомплектование персоналом, альтернативными ресурсами для средств обработки информации, а также меры по переходу на аварийный режим работы для этих средств.
 
 11.1.4 Структура планов обеспечения непрерывности бизнеса
 
 Следует поддерживать единую структуру планов обеспечения непрерывности бизнеса в целях обеспечения непротиворечивости всех планов и определения приоритетов для тестирования и обслуживания средств и систем обработки информации. Необходимо, чтобы каждый план обеспечения непрерывности бизнеса четко определял условия его реализации, а также должностных лиц, ответственных за выполнение каждого его пункта. При выявлении новых требований необходимо вносить соответствующие корректировки в процедуры на случай чрезвычайных ситуаций, например в планы эвакуации или в любые существующие планы по переходу на аварийный режим работы.
 
 Необходимо, чтобы в структуре планов обеспечения непрерывности бизнеса предусматривалось следующее:
 
 - условия реализации планов, которые определяют порядок действий должностных лиц, которому необходимо следовать (как оценивать ситуацию, кто должен принимать участие, и т. д.) перед введением в действие каждого пункта плана;
 
 - процедуры на случай чрезвычайных ситуаций, которые должны быть предприняты после инцидента, подвергающего опасности бизнес-операции и/или человеческую жизнь. Необходимо, чтобы они включали также меры по управлению связями с общественностью и эффективное взаимодействие с соответствующими государственными органами, например с милицией, пожарной охраной и местными органами власти;
 
 - процедуры перехода на аварийный режим работы, которые описывают необходимые действия по переносу важных бизнес-операций или сервисов-поддержки в альтернативное временное место размещения и по восстановлению бизнес-процессов в требуемые периоды времени;
 
 - процедуры возобновления работы, которые описывают необходимые действия для возвращения к нормальному режиму ведения бизнеса;
 
 - график поддержки плана, который определяет сроки и методы тестирования, а также описание процесса поддержки плана;
 
 - мероприятия по обучению персонала, которые направлены на понимание процессов обеспечения непрерывности бизнеса сотрудниками, и поддержание постоянной эффективности этих процессов;
 
 - обязанности должностных лиц, ответственных за выполнение каждого пункта плана. При необходимости должны быть указаны альтернативные ответственные.
 
 Необходимо, чтобы за каждый план отвечал конкретный руководитель (сотрудник). Чрезвычайные меры, планы по переходу на аварийный режим ручной обработки, планы по возобновлению работы следует включать в сферу ответственности владельцев соответствующих бизнес-ресурсов или участников затрагиваемых процессов. За меры по переходу на аварийный режим работы с использованием альтернативных технических средств, таких как средства обработки информации и связи, ответственность несут поставщики услуг.
 
 11.1.5 Тестирование, поддержка и пересмотр планов по обеспечению непрерывности бизнеса
 
 11.1.5.1 Тестирование планов
 
 Планы по обеспечению непрерывности бизнеса могут оказаться несостоятельными при тестировании из-за неправильных предпосылок разработки, недосмотру или вследствие изменений, связанных с заменой оборудования или персонала. Поэтому планы необходимо регулярно тестировать для обеспечения уверенности в их актуальности и эффективности. Такие тесты необходимы также для обеспечения знания своих обязанностей всеми членами команды восстановления и другим персоналом, имеющим к этому отношение.
 
 Необходимо, чтобы в графике тестирования плана по обеспечению непрерывности бизнеса указывалось, как и когда следует проверять каждый пункт плана. Периодичность и методы тестирования отдельных пунктов плана могут быть различными. При этом могут использоваться следующие методы:
 
 - тестирование ("имитация прогона") различных сценариев (обсуждение мер по восстановлению бизнеса на различных примерах прерываний);
 
 - моделирование (особенно для тренировки персонала по выполнению своих функций после инцидента и перехода к кризисному управлению);
 
 - тестирование технического восстановления (обеспечение уверенности в эффективном восстановлении информационных систем);
 
 - проверка восстановления в альтернативном месте (бизнес-процессы осуществляются параллельно с операциями по восстановлению в удаленном альтернативном месте);
 
 - тестирование средств и сервисов-поставщиков (обеспечение уверенности в том, что предоставленные сторонними организациями сервисы и программные продукты удовлетворяют контрактным обязательствам);
 
 - "генеральные репетиции" (тестирование того, что организация, персонал, оборудование, средства и процессы могут справляться с прерываниями).
 
 Методы тестирования могут использоваться любой организацией и необходимо, чтобы они отражали специфику конкретного плана по восстановлению.
 
 11.1.5.2 Поддержка и пересмотр планов
 
 Планы по обеспечению непрерывности бизнеса необходимо поддерживать в актуальном состоянии путем проведения регулярных пересмотров и обновлений с целью обеспечения уверенности в их постоянной эффективности (11.1.5.1). В рамках программы развития организации необходимо предусматривать соответствующие процедуры, обеспечивающие непрерывность бизнеса.
 
 Необходимо назначать ответственных за проведение регулярных пересмотров плана по обеспечению непрерывности бизнеса; идентифицированные изменения в бизнес-процессах, еще не отраженные в планах по обеспечению непрерывности бизнеса, должны быть учтены путем соответствующих обновлений планов. Формализованный процесс управления изменениями должен обеспечивать рассылку и ввод в действие обновленных планов в рамках их регулярных пересмотров.
 
 Примеры ситуаций, которые могли бы потребовать обновления планов, включают приобретение нового оборудования или обновление операционных систем, а также изменения, связанные с:
 
 - персоналом;
 
 - адресами или номерами телефонов;
 
 - стратегией бизнеса;
 
 - местоположением, средствами и ресурсами;
 
 - законодательством;
 
 - подрядчиками, поставщиками и основными клиентами;
 
 - процессами (как новыми, так и изъятыми);
 
 - рисками (операционными и финансовыми).
 

 
 12 Соответствие требованиям

 12.1 Соответствие требованиям законодательства
 

 Цель: предотвращение любых нарушений норм уголовного и гражданского права, обязательных предписаний и регулирующих требований или договорных обязательств, а также требований безопасности.
 
 Проектирование и функционирование информационных систем, их использование и управление ими могут быть предметом обязательных предписаний, регулирующих требований, а также требований безопасности в договорных обязательствах.
 
 Следует консультироваться с юристами организации или с практикующими юристами, имеющими соответствующую квалификацию, в отношении конкретных юридических вопросов. Следует иметь в виду, что законодательные требования в отношении информации, созданной в одной стране и переданной в другую страну (например, информационный поток, передаваемый за границу государства), различаются в разных странах.
 
 12.1.1 Определение применимого законодательства
 
 Все применяемые нормы законодательства, обязательные предписания, регулирующие требования и договорные обязательства, следует четко определять и документировать для каждой информационной системы. Конкретные мероприятия по обеспечению информационной безопасности и индивидуальные обязанности должностных лиц по выполнению этих требований необходимо соответствующим образом определять и документировать.
 
 12.1.2 Права интеллектуальной собственности
 
 12.1.2.1 Авторское право
 
 Необходимо внедрять процедуры, обеспечивающие соответствие законодательным ограничениям на использование материала, в отношении которого могут существовать права на интеллектуальную собственность, такие как авторское право, права на проект, торговые марки. Нарушение авторского права может привести к судебным процессам, предполагающим возможность уголовной ответственности.
 
 Законодательные, регулирующие и договорные требования могут вводить ограничения на копирование материалов, являющихся предметом собственности. В частности, эти ограничения могут содержать требования к использованию только тех материалов, которые или разработаны организацией, или лицензированы, или предоставляются разработчиком для организации.
 
 12.1.2.2 Авторское право на программное обеспечение
 
 Программные продукты, являющиеся предметом чьей-то собственности, обычно поставляются в рамках лицензионного соглашения, которое ограничивает использование продуктов определенными компьютерами, а также может ограничивать копирование их с целью создания резервных копий. В этих случаях для обеспечения информационной безопасности следует предусматривать применение следующих мероприятий:
 
 - строгое следование требованиям авторского права на программное обеспечение, которое определяет законное использование программных и информационных продуктов;
 
 - определение порядка и правил приобретения программных продуктов;
 
 - обеспечение осведомленности сотрудников по вопросам авторского права на программное обеспечение принятых правил в отношении закупок, а также уведомление о применении дисциплинарных санкций к нарушителям;
 
 - ведение соответствующих регистров активов;
 
 - ведение подтверждений и доказательств собственности на лицензии, дистрибутивные диски, руководства и т. д.;
 
 - контроль за соблюдением ограничений максимального числа разрешенных пользователей программными продуктами;
 
 - регулярные проверки применения только авторизованного программного обеспечения и лицензированных продуктов;
 
 - реализация политики по обеспечению выполнения условий соответствующих лицензионных соглашений;
 
 - выполнение правил утилизации или передачи программного обеспечения в другие организации;
 
 - организация регулярного аудита;
 
 - соблюдение условий получения из общедоступных сетей программного обеспечения и информации (8.7.6).
 
 12.1.3 Защита учетных записей организации
 
 Важные данные организации необходимо защищать от утраты, разрушения и фальсификации. В отношении некоторых данных может потребоваться обеспечение безопасности хранения с целью выполнения законодательных или регулирующих требований, а также поддержки важных бизнес-приложений. В качестве примеров можно привести данные, которые могут потребоваться для доказательства того, что организация работает в рамках установленных законом норм или регулирующих требований, или с целью адекватной защиты от гражданского или уголовного преследования, а также подтверждения финансового состояния организации для акционеров, партнеров и аудиторов. Период времени хранения и содержание данных могут быть установлены в соответствии с государственными законами или регулирующими требованиями.
 
 Данные необходимо классифицировать по типам, например, бухгалтерские записи, записи баз данных, журналы транзакций, журналы аудита и операционных процедур, каждый с указанием периодов хранения и типов носителей хранимых данных (бумага, микрофильм, магнитные или оптические носители). Любые криптографические ключи, связанные с зашифрованными архивами или цифровыми подписями (10.3.2 и 10.3.3), следует хранить безопасным способом и предоставлять к ним, при необходимости, доступ только авторизованным лицам.
 
 Следует учитывать возможность снижения качества носителей, используемых для хранения данных, осуществлять процедуры по хранению и уходу за носителями данных в соответствии с рекомендациями изготовителя.
 
 При использовании электронных носителей данных следует применять процедуры проверки возможности доступа к данным (например, читаемость как самих носителей, так и формата данных) в течение периода их хранения с целью защиты от потери вследствие будущих изменений в информационных технологиях.
 
 Системы хранения данных следует выбирать таким образом, чтобы требуемые данные могли быть извлечены способом, приемлемым для суда, действующего по нормам гражданского или общего права, например, возможность вывода всех необходимых записей в приемлемый период времени и в приемлемом формате.
 
 Необходимо, чтобы система хранения обеспечивала четкую идентификацию данных, а также период их хранения, установленных законом или регулирующими требованиями. Эта система должна предоставлять возможности по уничтожению данных после того периода, когда у организации отпадет потребность в их хранении.
 
 С целью выполнения данных обязательств организации следует:
 
 - разработать руководство в отношении сроков, порядка хранения и утилизации информации;
 
 - составить график хранения наиболее важных данных;
 
 - вести опись источников ключевой информации;
 
 - внедрить соответствующие меры для защиты важной информации от потери, разрушения и фальсификации.
 
 12.1.4 Защита данных и конфиденциальность персональной информации
 
 В ряде стран введены нормы законодательства, в которых установлены ограничения в отношении обработки и передачи персональных данных (в основном, это касается информации о живущих людях, которые могут быть идентифицированы по этой информации). Такие ограничения могут налагать обязанности на тех, кто осуществляет сбор, обработку и распространение личной информации, а также могут ограничивать возможность передачи этих данных в другие страны.
 
 Соответствие законодательству по защите данных требует соответствующей структуры управления информационной безопасностью. Лучше всего это достигается при назначении должностного лица, отвечающего за защиту данных путем соответствующего разъяснения менеджерам, пользователям и поставщикам услуг об их индивидуальной ответственности, а также обязательности выполнения соответствующих мероприятий по обеспечению информационной безопасности. Владельцы данных обязаны информировать это должностное лицо о любых предложениях, о способах хранения персональной информации в структуре файла данных, а также знать применяемые нормы законодательства в отношении защиты личных данных.
 
 12.1.5 Предотвращение нецелевого использования средств обработки информации
 
 Средства обработки информации организации предназначены для обеспечения потребностей бизнеса.
 
 Руководство должно определить уровни полномочий пользователей в отношении использования средств обработки информации. Любое использование этих средств для непроизводственных или неавторизованных целей, без одобрения руководства, следует расценивать как нецелевое. Если такая деятельность выявлена мониторингом или другими способами, то на это следует обратить внимание непосредственного руководителя сотрудника для принятия соответствующих мер дисциплинарного воздействия.
 
 Законность использования мониторинга зависит от действующего в стране законодательства и может потребоваться, чтобы сотрудники были осведомлены и дали документированное согласие на проведение мониторинга. Перед осуществлением мониторинга необходимо получить консультацию юриста.
 
 Многие страны имеют или находятся в процессе введения законодательства по защите от неправильного использования компьютеров. Возможны случаи использования компьютера для неавторизованных целей с преступным умыслом. Поэтому важно, чтобы все пользователи были осведомлены о четких рамках разрешенного им доступа. Это может быть достигнуто, например, путем ознакомления пользователей с предоставленной им авторизацией в письменной форме под роспись, а организации следует безопасным способом хранить копию этого документа. Необходимо, чтобы сотрудники организации и пользователи третьей стороны были осведомлены о том, что во всех случаях они имеют право доступа только к тем данным, использование которых им разрешено.
 
 Необходимо, чтобы при регистрации доступа к системе на экране компьютера было отражено предупреждающее сообщение, указывающее, что система, вход в которую пользователи пытаются осуществить, является системой с ограниченным доступом, и что неавторизованный доступ к ней запрещен. Пользователь должен подтвердить это прочтение и реагировать соответствующим образом на него, чтобы продолжить процесс регистрации.
 
 12.1.6 Регулирование использования средств криптографии
 
 В некоторых странах приняты соглашения, законы, регулирующие требования или другие инструменты, определяющие мероприятия по обеспечению безопасности доступа к криптографическим средствам и их использованию. Такие мероприятия обычно включают:
 
 - ограничения импорта и/или экспорта аппаратных и программных средств для выполнения криптографических функций;
 
 - ограничения импорта и/или экспорта аппаратных и программных средств, которые разработаны таким образом, что имеют, как дополнение, криптографические функции;
 
 - обязательные или дискреционные методы доступа со стороны государства к информации, зашифрованной с помощью аппаратных или программных средств для обеспечения конфиденциальности ее содержания.
 
 Для обеспечения уверенности в соответствии политики использования криптографических средств в организации национальному законодательству необходима консультация юриста. Прежде чем зашифрованная информация или криптографическое средство будут переданы в другую страну, необходимо также получить консультацию юриста.
 
 12.1.7 Сбор доказательств
 
 12.1.7.1 Правила использования и сбора доказательств
 
 Необходимо иметь адекватные свидетельства, чтобы поддерживать иски или меры воздействия, направленные против физического лица или организации, которые нарушили правила управления информационной безопасностью.
 
 Всякий раз, когда эти меры воздействия являются предметом внутреннего дисциплинарного процесса, свидетельства должны быть описаны в соответствии с внутренними процедурами.
 
 Когда меры воздействия/иски затрагивают вопросы как гражданского, так и уголовного права, необходимо, чтобы представленные свидетельства соответствовали требованиям к сбору свидетельств, изложенными в соответствующих правовых нормах или требованиям конкретного суда, в котором будет рассматриваться данный вопрос. В общем случае, эти правила предусматривают:
 
 - допустимость свидетельств: действительно ли свидетельства могут использоваться в суде или нет;
 
 - весомость свидетельств: качество и полнота свидетельств;
 
 - адекватное свидетельство того, что эти меры контроля (процесс сбора свидетельств) осуществлялись корректно и последовательно в течение всего периода, когда установленное свидетельство инцидента нарушения информационной безопасности было сохранено и обработано системой.
 
 12.1.7.2 Допустимость доказательств
 
 Чтобы достичь признания допустимости свидетельств, организациям необходимо обеспечить уверенность в том, что их информационные системы соответствуют всем юридическим требованиям и правилам в отношении допустимых свидетельств.
 
 12.1.7.3 Качество и полнота доказательств
 
 Чтобы достичь качества и полноты свидетельств, необходимо наличие убедительных подтверждений свидетельств. В общем случае, такие убедительные подтверждения могут быть достигнуты следующим образом:
 
 - для бумажных документов: оригинал хранится безопасным способом и фиксируется, кто нашел его, где он был найден, когда он был найден и кто засвидетельствовал обнаружение. Необходимо, чтобы любое исследование подтвердило, что оригиналы никто не пытался исказить;
 
 - для информации на компьютерных носителях: копии информации, для любых сменных носителей информации, для жестких дисков или из основной памяти компьютера, следует выполнять таким образом, чтобы обеспечить их доступность. Журнал всех действий, выполненных в течение процесса копирования, необходимо сохранять, а сам процесс копирования необходимо документировать. Одну копию носителей информации и журнал следует хранить безопасным способом.
 
 Когда инцидент обнаруживается впервые, не очевидно, что он может привести к возможным судебным разбирательствам. Поэтому, существует опасность, что необходимое показание будет случайно разрушено прежде, чем осознана серьезность инцидента. Целесообразно на самом раннем этапе привлекать юриста или милицию в любом случае предполагаемых судебных разбирательств и получать консультацию относительно требуемых свидетельств.
 
 12.2 Пересмотр политики безопасности и техническое соответствие требованиям безопасности
 
 Цель: обеспечение соответствия систем политике безопасности организации и стандартам.
 
 Безопасность информационных систем необходимо регулярно анализировать и оценивать.
 
 Такой анализ (пересмотр) необходимо осуществлять в отношении соответствующих политик безопасности, а программные средства и информационные системы должны подвергаться аудиту на предмет соответствия этим политикам.
 
 12.2.1 Соответствие политике безопасности
 
 Руководители должны обеспечивать правильное выполнение всех процедур безопасности в пределах их зоны ответственности. Кроме того, все сферы деятельности организации необходимо подвергать регулярному пересмотру для обеспечения требований по обеспечению информационной безопасности. При этом, кроме функционирования информационных систем, анализу должна подвергаться также деятельность:
 
 - поставщиков систем;
 
 - владельцев информации и информационных активов;
 
 - пользователей;
 
 - руководства.
 
 Владельцам информационных систем (5.1) следует проводить регулярные мониторинги их систем на соответствие принятым политикам безопасности и любым другим требованиям безопасности.
 
 Вопросы мониторинга использования систем рассмотрены в 9.7.
 
 12.2.2 Проверка технического соответствия требованиям безопасности
 
 Проверка технического соответствия включает испытания операционных систем для обеспечения уверенности в том, что мероприятия по обеспечению информационной безопасности функционирования аппаратных и программных средств были внедрены правильно. Этот тип проверки соответствия требует технической помощи специалиста. Данную проверку следует осуществлять вручную (при помощи соответствующих инструментальных и программных средств, при необходимости) опытному системному инженеру или с помощью автоматизированного пакета программ, который генерирует технический отчет для последующего анализа техническим специалистом.
 
 Проверка соответствия также включает тестирование на наличие попыток несанкционированного доступа к системе (проникновение), которое может быть выполнено независимыми экспертами, специально приглашенными по контракту для этого. Данное тестирование может быть полезным для обнаружения уязвимостей в системе и для проверки эффективности мер безопасности при предотвращении неавторизованного доступа вследствие этих уязвимостей. Особую осторожность следует проявлять в случаях, когда тест на проникновение может привести к компрометации безопасности системы и непреднамеренному использованию других уязвимостей.
 
 Любая проверка технического соответствия должна выполняться только компетентными, авторизованными лицами либо под их наблюдением.
 
 

 12.3 Меры безопасности при проведении аудита

 
 Цель: максимизация эффективности и минимизация влияния на информационную безопасность в процессе аудита системы.
 
 Необходимо предусматривать мероприятия по обеспечению информационной безопасности операционной среды и инструментальных средств аудита в процессе проведения аудита систем.
 
 Защита также требуется для поддержания целостности информационной системы и предотвращения неправильного использования инструментальных средств аудита.
 
 12.3.1 Мероприятия по обеспечению информационной безопасности при проведении аудита систем
 
 Требования и действия аудита, включающие проверку операционных систем, необходимо тщательно планировать и согласовывать, чтобы свести к минимуму риск для бизнес-процессов. Необходимо учитывать следующее:
 
 - требования аудита необходимо согласовать с соответствующим руководством;
 
 - объем работ по проверкам следует согласовывать и контролировать;
 
 - при проведении проверок необходимо использовать доступ только для чтения к программному обеспечению и данным;
 
 - другие виды доступа могут быть разрешены только в отношении изолированных копий файлов системы, которые необходимо удалять по завершению аудита;
 
 - необходимо четко идентифицировать и обеспечивать доступность необходимых ресурсов информационных систем для выполнения проверок;
 
 - требования в отношении специальной или дополнительной обработки данных следует идентифицировать и согласовывать;
 
 - весь доступ должен подвергаться мониторингу и регистрироваться с целью обеспечения протоколирования для последующих ссылок;
 
 - все процедуры, требования и обязанности аудита следует документировать.
 
 12.3.2 Защита инструментальных средств аудита систем
 
 Доступ к инструментальным средствам аудита систем, то есть программному обеспечению или файлам данных, необходимо защищать, чтобы предотвратить любое возможное их неправильное использование или компрометацию. Такие инструментальные средства необходимо отделять от систем разработки и систем операционной среды, а также не хранить эти средства в библиотеках магнитных лент или пользовательских областях, если не обеспечен соответствующий уровень дополнительной защиты.
 
 
 

Текст документа сверен по:
официальное издание
М.: Стандартинформ, 2006

Из за большого объема эта статья размещена на нескольких страницах:
1 2 3 4 5