Руководство для систем безопасности

ФЕДЕРАЛЬНАЯ СЛУЖБА ВОЙСК НАЦИОНАЛЬНОЙ ГВАРДИИ
РОССИЙСКОЙ ФЕДЕРАЦИИ

ГЛАВНОЕ УПРАВЛЕНИЕ ВНЕВЕДОМСТВЕННОЙ ОХРАНЫ

Утверждены
Начальником ГУВО Росгвардии
генерал-лейтенантом полиции
А.В.ГРИЩЕНКО
1 марта 2022 г.

РЕКОМЕНДАЦИИ
ПО ОХРАНЕ ОСОБО ВАЖНЫХ ОБЪЕКТОВ С ПРИМЕНЕНИЕМ
ИНТЕГРИРОВАННЫХ СИСТЕМ БЕЗОПАСНОСТИ

Р 089-2022

АННОТАЦИЯ

В Рекомендациях приведены общие требования к интегрированным системам безопасности (ИСБ), требования к базовым системам ИСБ, общие требования к техническим средствам ИСБ, требования к отдельным вспомогательным и дополнительным системам ИСБ. Рассмотрены вопросы выбора, проектирования и ввода в эксплуатацию ИСБ. Приведена информация о применении ИСБ на взрывоопасных объектах. Представлены перспективы развития ИСБ, переход к PSIM (ПСИМ) — системам.

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

Обозначения и сокращения

АРМ — автоматизированное рабочее место

АТС — автоматическая телефонная станция

БИ — блок излучателя

БП — блок приемника

ГОСТ — межгосударственный стандарт

ГОСТ Р — государственный стандарт Российской Федерации

ГУВО Росгвардии — Главное управление вневедомственной охраны Федеральной службы войск национальной гвардии Российской Федерации

ИСБ — интегрированная система безопасности

ИЭПВР — источник электропитания вторичный с резервом

КПП — контрольно-пропускной пункт

КУД — контроль и управление доступом

МПХИГ — место проживания и хранения имущества граждан

ПО — программное обеспечение

ПУЭ — Правила устройства электроустановок

ПЦО — пункт централизованной охраны

РЭ — руководство по эксплуатации

СКУД — система контроля и управления доступом

СОС — система охранной сигнализации

СОТ — система охранная телевизионная

СПИ — система передачи извещений

СТН — система телевизионного наблюдения

СТС — система тревожной сигнализации

СУ — средства управления

СЦН — система централизованного наблюдения

ТС — техническое средство

ТУ — технические условия

УИ — исполнительное устройство

УПУ — устройство преграждающее управляемое

УС — устройство считывающее

ФГУП «Охрана» Росгвардии — Федеральное государственное унитарное предприятие «Охрана» Федеральной службы войск национальной гвардии Российской Федерации

ФКУ «НИЦ «Охрана» Росгвардии — Федеральное казенное учреждение «Научно-исследовательский центр «Охрана» Федеральной службы войск национальной гвардии Российской Федерации

ШС — шлейф сигнализации

ЭВМ — электронно-вычислительная машина

Термины и определения

В данных рекомендациях применены следующие термины с соответствующими им определениями.

автоматизированное рабочее место; АРМ — Персональное рабочее место, обеспечивающее автоматизацию взаимодействия сотрудника пункта централизованной охраны (мониторингового центра) с СЦН

антитеррористическая защита объекта — Деятельность, осуществляемая с целью повышения устойчивости объекта к террористическим угрозам

безопасность — Состояние защищенности жизненно важных интересов личности, общества и государства от внутренних и внешних угроз

взятие объекта под охрану — Штатное выполнение процедур по постановке объекта на охрану

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

видеонаблюдение — Четкое изображение в пределах установленных зон при заданных уровнях освещенности и ожидаемых производственных помехах

вневедомственная охрана — Структурное подразделение Росгвардии, предоставляющее услуги по охране объектов всех форм собственности, а также МПХИГ

заказчик — Юридическое или физическое лицо, несущее ответственность за обеспечение противокриминальной защиты объекта

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

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

извещение — Передаваемая информация о состоянии охраняемого объекта или технического средства охраны

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

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

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

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

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

локальная охрана — Охрана зон с передачей информации о состоянии технических средств охраны в пределах объекта

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

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

несанкционированный доступ — Доступ субъектов или объектов, не имеющих права доступа

нештатная ситуация — Положение нарушения охраны объекта, не предусмотренное регламентирующими документами

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

оповещатель световой — Оповещатель, выдающий световые сигналы

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

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

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

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

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

устройство преграждающее управляемое; УПУ — Устройство, обеспечивающее физическое препятствие доступу и оборудованное исполнительными устройствами для управления его состоянием (турникеты, шлюзы, проходные кабины, двери и ворота, оборудованные исполнительными устройствами СКУД, а также другие подобные устройства)

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

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

система контроля и управления доступом; СКУД — Совокупность совместно действующих технических средств, предназначенных для контроля и управления доступом и обладающих технической, информационной, программной и эксплуатационной совместимостью

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

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

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

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

система тревожной сигнализации; СТС — Электрическая установка, предназначенная для обнаружения и сигнализации о наличии опасности

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

снятие объекта с охраны — Штатное выполнение процедур по прекращению обеспечения техническими средствами охраны объекта

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

средства управления; СУ — Аппаратные средства (устройства) и программные средства, обеспечивающие установку режимов доступа, прием и обработку информации со считывателей, проведение идентификации и аутентификации, управление исполнительными и преграждающими устройствами, отображение и регистрацию информации

техническое средство СОТ, ТС СОТ — Конструктивно и функционально законченное устройство, входящее в состав системы

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

шлейф сигнализации; ШС — Электрическая цепь, линия связи, предназначенные для передачи извещений на средство сбора и обработки информации

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

Введение

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

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

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

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

Для решения этой проблемы специалистами ФКУ «НИЦ «Охрана» Росгвардии совместно с ГУВО Росгвардии, в рамках деятельности технического комитета по стандартизации «Системы тревожной сигнализации и противокриминальной защиты» (ТК 234), был разработан национальный стандарт Российской Федерации ГОСТ Р 57674-2017, в котором устанавливаются основные положения функционального назначения ИСБ, их состава, а также вводится система терминов и их определений, предназначенных для формирования единого технического языка в области ИСБ с перспективой применения при разработке нормативных правовых актов Российской Федерации, ведомственных нормативно-технических документов, стандартов организаций, технических условий на ИСБ различных производителей и другой технической документации.

Приказом Федерального агентства по техническому регулированию и метрологии (Росстандарт) от 19 сентября 2017 года N 1142-ст данный национальный стандарт был утвержден и введен в действие с 1 июня 2018 года.

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

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

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

В соответствии со «Списком технических средств безопасности, удовлетворяющих «Единым требованиям к системам передачи извещений, объектовым техническим средствам охраны и охранным сигнально-противоугонным устройствам автотранспортных средств, предназначенным для применения в подразделениях вневедомственной охраны войск национальной гвардии Российской Федерации» для применения в подразделениях вневедомственной охраны рекомендованы следующие ИСБ: «Кодос А-20» (ОАО «КОДОС», г. Москва), «Ладога-А» (ООО НПП «Риэлта», г. Санкт-Петербург), «Р-08» (ООО «Викинг», г. Москва), «Стрелец-Интеграл» (ЗАО «Аргус-Спектр», г. Санкт-Петербург), «Орион» (ЗАО НВП «Болид», г. Королев, МО), «Рубеж-СБ» (ООО «КБ Пожарной Автоматики», г. Саратов). По всем перечисленным ИСБ проведены необходимые организационно-технические мероприятия:

— получены необходимые сертификаты;

— проведены технические экспертизы ИСБ;

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

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

Кроме того, со стороны ГУВО Росгвардии и ФКУ «НИЦ «Охрана» Росгвардии осуществляется постоянный контроль качества серийного производства ИСБ и авторский надзор за вносимыми в них схемными, конструктивными и программными изменениями.

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

Целью настоящих рекомендаций является оказание информационно-методической помощи подразделениям вневедомственной охраны, ФГУП «Охрана» Росгвардии, сотрудникам служб безопасности различных организаций при применении ИСБ, а также специалистам проектномонтажных организаций при проектировании и оборудовании объектов ИСБ.

1 Общие требования к ИСБ

1.1 Требования к функциональному составу ИСБ и извещениям

В соответствии с терминологией, принятой ГОСТ Р 57674-2017, Интегрированная система безопасности — это система безопасности объекта, объединяющая в себе целевые функциональные системы, предназначенные для защиты от угроз различной природы возникновения и характера проявления.

В стандарте определено, что в состав ИСБ должно входить не менее трех из следующих базовых систем:

— СТС;

— СОС;

— СОТ;

— СКУД.

Функциональная схема ИСБ, состоящей из базовых систем, приведена на рисунке 1.1.

Рисунок 1.1

Допускается функциональное объединение СТС и СОС, при этом, в составе ИСБ их учитывают по отдельности.

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

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

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

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

— обеспечение возможности ручного управления системами, входящими в состав ИСБ;

— ведение электронного протокола функционирования систем, входящих в состав ИСБ, с регистрацией его в базе данных;

— модификация состава и конфигурации ИСБ, в соответствии с изменением задач, решаемых ИСБ.

Помимо обязательных, ИСБ может выполнять вспомогательные и дополнительные функции, не связанные с обеспечением противокриминальной безопасности. Состав ИСБ может быть дополнен иными системами обеспечения безопасности по ГОСТ Р 53195.1-2008.

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

Рисунок 1.2

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

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

По виду организации противокриминальной защиты ИСБ подразделяются на локальные и централизованные.

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

Централизованная ИСБ предназначена для обеспечения противокриминальной защиты объекта, охрана которого осуществляется при помощи системы централизованного наблюдения (СЦН).

В стандарте введены требования по составу обязательных извещений, передаваемых на автоматизированные рабочие места (АРМ) ИСБ (для локальных ИСБ) и АРМ СЦН (для централизованных ИСБ), а также отображаемых на внутренних и/или внешних устройствах отображения (оповещатели, индикаторы, индикаторные панели и т.п.).

К обязательным извещениям, передаваемым на АРМ, относятся следующие извещения:

— переход в дежурный режим;

— переход в тревожный режим;

— отключение основного электропитания и переход на резервное;

— восстановление основного электропитания;

— неисправность технических средств, входящих в состав ИСБ (в том числе — разряд аккумуляторных батарей), интерфейсов и линии связи;

— взятие объекта (зоны) под охрану;

— снятие объекта (зоны) с охраны.

К извещениям, отображаемым на внутренних и/или внешних устройствах отображения, относятся следующие извещения:

— переход в дежурный режим;

— переход в тревожный режим;

— взятие объекта (зоны) под охрану;

— снятие объекта (зоны) с охраны.

1.2 Принципы интеграции ИСБ

При объединении различных систем в составе ИСБ возможно применение нескольких типов интеграции.

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

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

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

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

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

К недостаткам можно отнести:

— ограниченность видов извещений, которыми могут обмениваться системы;

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

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

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

Структурная схема ИСБ при программной интеграции приведена на рисунке 1.3.

Рисунок 1.3

Существуют два подхода к созданию специализированного ПО для ИСБ:

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

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

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

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

Аппаратно-программная интеграция — наиболее распространенный тип интеграции ИСБ. В этом случае аппаратные и программные средства разрабатываются в рамках единой системы. Это позволяет достигнуть оптимальных характеристик, так как вся разработка сосредоточена, как правило, у одного предприятия-изготовителя и система как законченный продукт поставляется с полной гарантией. При этом, возможно также получить оптимальные экономические показатели.

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

Аппаратно-программная интеграция может включать четыре уровня. Пример функциональной схемы четырехуровневой ИСБ при аппаратно-программной интеграции приведен на рисунке 1.4.

Рисунок 1.4

Первый уровень аппаратно-программной интеграции ИСБ обеспечивает связь между сервером ИСБ, одним или несколькими АРМ, в том числе для территориально рассредоточенных объектов. Первый уровень аппаратно-программной интеграции ИСБ представляет собой локальную сеть на основе стандартов Ethernet и специализированного программного обеспечения.

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

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

Четвертый уровень аппаратно-программной интеграции ИСБ представляет собой электрические цепи и линии связи, предназначенные для обеспечения контроля и управления техническими средствами (ТС) без использования цифрового обмена данными (безадресные извещатели, оповещатели, релейные исполнительные устройства и др.).

2 Параметры базовых систем ИСБ

2.1 Общие положения

ИСБ должны соответствовать требованиям ГОСТ Р 57674-2017. Обязательным требованием является наличие общих ТУ, комплекта эксплуатационной документации, паспорт, руководство по работе с ПО и другие общесистемные документы). Помимо общей эксплуатационной документации, при необходимости, отдельные компоненты ИСБ могут комплектоваться частной эксплуатационной документацией. Поставка ИСБ заказчику должна производиться от одной вендорной компании, которая несет ответственность по гарантийным обязательствам по всем компонентам ИСБ.

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

Возникновение криминальной угрозы, выявленной СТС, СОС или СОТ должно переводить СКУД в режим реагирования на соответствующую криминальную угрозу, по алгоритму, учитывающему специфику защищаемого объекта.

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

2.2 Параметры аппаратных средств и ПО ИСБ

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

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

Технические характеристики протоколов обмена информацией и интерфейсов ИСБ должны указываться в ТУ и эксплуатационной документации на конкретные компоненты.

Общие требования к ПО ИСБ, заданные в ТУ должны соответствовать ГОСТ 28195-89.

ПО ИСБ должно быть устойчиво к следующего вида:

— отключение электропитания;

— программный сброс;

— аппаратный сброс технических средств;

— случайное нажатие клавиш на клавиатуре;

— случайный перебор пунктов меню.

После указанных воздействий и перезапуска ПО, должна обеспечиваться работоспособность ИСБ и сохранность настроек и ранее полученных данных.

ИСБ должно обеспечивать возможность одновременного использования нескольких типов АРМ с разделением операторов АРМ по предоставленным полномочиям и правам доступа: просмотр информации, управление ИСБ, администрирование.

2.3 Технические и организационные мероприятия по защите информации ИСБ

В системах ИСБ должны быть приняты следующие меры по защите информации:

— защита компонентов ИСБ от несанкционированных действий внешних и внутренних нарушителей;

— защита информации в линиях связи и местах ее хранения.

Технические мероприятия по защите информации и обеспечению внутренней безопасности ИСБ необходимо строить по следующим направлениям:

— ограничение доступа к местам размещения пультов АРМ, пультов управления ИСБ;

— идентификация пользователей ИСБ;

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

— регистрация и учет работы пользователей;

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

— резервирование важных для функционирования ИСБ областей данных;

— кодирование информации;

— контроль вскрытия аппаратуры.

Организационные мероприятия по защите информации заключаются в разработке и реализации административных и организационных мер по подготовке к эксплуатации ИСБ. К ним относятся:

— ограничение количества должностных лиц, допущенных к работе с ИСБ;

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

— разделение функций технического обслуживания и ремонта от функций администрирования ИСБ;

— периодическая смена паролей.

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

— постановка на учет носителей информации и документации;

— проверка отсутствия посторонней аппаратуры;

— защита аппаратуры от электромагнитного излучения и наводок;

— периодическая проверка системы контроля вскрытия аппаратуры.

ПО ИСБ должно быть защищено от несанкционированного доступа.

Рекомендуемые уровни защиты доступа к ПО ИСБ с помощью паролей с разделением по типу пользователей:

— первый («администратор») — доступ ко всем функциям;

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

— третий («системный оператор») — доступ к функциям конфигурации ПО без доступа к функциям управления СКУД.

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

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

2.4 Параметры СОС и СТС

СОС и СТС, входящие в состав ИСБ, должны:

— осуществлять контроль состояния ШС;

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

— осуществлять управление постановкой и снятием с охраны;

— обеспечивать возможность формирования и передачи тревожных и служебных извещений на АРМ локальной ИСБ и (или) АРМ СЦН;

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

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

В СОС и СТС должна быть исключена возможность игнорирование состояния ШС программными методами.

Адресные и безадресные ШС СОС и СТС должны соответствовать требованиям ГОСТ 52436-2005.

Время от момента перехода любого адресного извещателя в тревожный режим до момента отображения тревожного извещения на световых и звуковых охранных оповещателях, индикаторных панелях, пультах управления, АРМ не должно превышать 10 с.

В СОС и СТС должны быть реализованы функции управления внешними световым и звуковым оповещателями со следующей тактикой оповещения.

Для светового оповещателя:

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

— СОС и СТС в дежурном режиме — оповещатель находится в режиме непрерывного свечения;

— СОС и СТС в тревожном режиме — оповещатель находится в режиме прерывистого свечения с частотой повторения от 0,5 до 2 Гц.

Для звукового оповещателя:

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

— СОС и СТС в тревожном режиме — оповещатель включен на ограниченное время.

ТС, входящие в состав СОС и СТС, должны иметь возможность программного или аппаратного задания следующих тактик работы релейных выходов: «охранный ПЦН», «световой оповещатель», «звуковой оповещатель».

Требования к устройствам постановки/снятия с охраны

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

В ТС, с помощью которых осуществляется постановка на охрану и снятие с охраны, не допускается применение в качестве устройств снятия с охраны тумблеров, кнопок и т.п.

Изменение настроек и режимов работы ТС СОС и СТС должно быть невозможно при нахождении СОС и СТС в режиме охраны.

Сигналы СТС должны отличаться от других сигналов.

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

СТС должна работать по принципу «без права отключения», во время нахождения людей на охраняемом объекте.

Вызывные устройства СТС должны устанавливаться:

— в кабинетах руководителей;

— в помещениях службы охраны;

— на постах и в помещениях охраны, расположенных в здании, строении, сооружении и на охраняемой территории;

— в помещениях КПП, бюро пропусков;

— в помещениях критических элементов объекта;

— на маршрутах передвижения охраны;

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

— в хранилищах, кладовых, сейфовых комнатах;

— в помещениях хранения оружия и боеприпасов;

— на рабочих местах кассиров;

— у центрального входа в здание и запасных выходах из него;

— в коридорах, у дверей и проемов, через которые производится перемещение ценностей;

— на охраняемой территории у центрального входа (въезда) и запасных выходах (выездах);

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

Извещатели СТС должны размещаться в местах, по возможности незаметных для посторонних.

Руководителей объекта, сотрудников службы безопасности и охраны следует оснащать мобильными беспроводными устройствами СТС (радиокнопками или радиобрелоками).

2.5 Параметры СКУД

СКУД должны соответствовать требованиям ГОСТ Р 51241-2008. ТС СКУД, относящиеся к УПУ, должны соответствовать требованиям ГОСТ Р 54831-2011.

СКУД должны обеспечивать:

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

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

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

В состав СКУД должны входить:

— УС в составе считывателей и идентификаторов;

— СУ в составе аппаратных и программных средств;

— УПУ в составе преграждающих конструкций и исполнительных устройств.

СКУД должна выполнять следующие основные функции:

— открывание УПУ после считывания идентификационного признака, доступ по которому разрешен в данную зону доступа (помещение или территорию) в заданный временной интервал или по команде оператора СКУД;

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

— санкционированное изменение (добавление, удаление) идентификационных признаков в СУ и связь их с зонами доступа (помещениями) и временными интервалами доступа;

— защиту от несанкционированного доступа к программным средствам СУ для изменения (добавления, удаления) идентификационных признаков;

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

— сохранение настроек и базы данных идентификационных признаков при отключении электропитания;

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

— открытие или блокировку любых дверей, оборудованных СКУД, с рабочего места оператора системы;

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

— автоматическое закрытие УПУ при отсутствии факта прохода через определенное время после считывания разрешенного идентификационного признака;

— закрытие УПУ на определенное время и выдачу сигнала тревоги при попытках подбора идентификационных признаков (кода);

— отображение на пульте оператора, регистрацию и протоколирование текущих и тревожных событий;

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

— автономную работу считывателя с УПУ в каждой точке доступа при отказе связи с СУ;

— возможность архивирования базы и просмотра архива в автономном режиме;

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

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

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

— учет клиентов системы по типу пропусков:

— постоянные пропуска (действуют на все время работы сотрудника);

— временные пропуска (действуют на определенный срок и удаляются из системы автоматически по окончании этого срока);

— гостевые пропуска (дают право прохода на одно посещение).

УС должны обеспечивать:

— считывание идентификационного признака с идентификаторов;

— обмен информацией с СУ.

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

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

СУ должно обеспечивать:

— прием информации от УС, ее обработку, отображение в заданном виде и выработку сигналов управления УПУ;

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

— ведение электронного журнала регистрации прохода работников через точки доступа;

— приоритетный вывод информации о тревожных ситуациях в точках доступа;

— контроль исправности состояния УПУ, УС и линий связи.

СКУД должна обеспечивать организацию пропускного и внутриобъектового режима на объектах и предусматривать разделение объекта на три основные зоны доступа:

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

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

— третья зона — специальные помещения объекта, доступ в которые имеют строго определенные сотрудники и руководители.

Пропуск работников на объект через точки доступа должен осуществляться:

— в первой зоне доступа по одному признаку идентификации;

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

— в третьей зоне доступа — не менее чем по двум признакам идентификации.

СКУД рекомендуется оборудовать:

— въездную группу (управление шлагбаумом на центральном въезде — выезде);

— турникеты входов в здание;

— кабинеты руководства;

— двери выходов из лифтовых холлов;

— служебные входы;

— помещения охраны;

— помещения, в которых непосредственно сосредоточены материальные ценности;

— режимные помещения и зоны ограниченного доступа (АТС, серверные, кроссовые, аппаратные, диспетчерские пункты, помещения жизнеобеспечения здания и т.п.);

помещения, согласованные с руководителем объекта дополнительно в ходе проектирования.

СКУД должна содержать следующие АРМ:

— АРМ администратора;

— АРМ дежурного оператора охраны;

— АРМ оператора на проходной;

— АРМ бюро пропусков;

— АРМ отдела кадров.

Функции отдельных АРМ СКУД могут объединяться на одном рабочем месте.

2.6 Параметры СОТ

СОТ должна соответствовать требованиям ГОСТ Р 51558-2014.

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

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

Видеокамеры СОТ могут также включаться по сигналу видеодетектора движения (аппаратного устройства или программно реализованного в составе АРМ СОТ), однако видеодетектор движения не может использоваться в качестве охранного извещателя СОТ.

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

СОТ должны обеспечивать возможность выполнения следующих функций:

— визуальный контроль объектов охраны и прилегающих к ним территорий;

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

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

— программирование режимов работы;

— функционирование под управлением систем контроля и управления доступом и охранной сигнализации.

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

Цифровые СОТ обеспечивают выполнение ряда дополнительных функций:

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

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

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

— цифровое (2/4/8/16-кратное) увеличение для детального анализа событий и идентификации лиц, предметов, номерных знаков автомобилей и т.п.;

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

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

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

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

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

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

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

— оперативный доступ к любому записанному кадру или последовательности кадров путем задания времени, даты и идентификатора телекамеры;

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

На объекте СОТ следует оборудовать:

— периметр территории;

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

— помещения постов охраны (на случай нападения на пост и в целях контроля несения службы);

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

— главный и запасные входы/выходы;

— критические и уязвимые места и зоны объекта;

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

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

— погрузочные терминалы;

— хранилища товарной продукции;

— хранилища вредных и опасных веществ;

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

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

Телекамеры, предназначенные для контроля территории объекта или ее периметра, должны работать при температуре окружающего воздуха от минус 40 °C до плюс 50 °C (от минус 50 °C до плюс 55 °C для климатических зон с холодным климатом) и размещаться в герметичных термокожухах, имеющих солнцезащитный козырек.

Телекамеры должны быть ориентированы на местности под углом к линии горизонта (лучи восходящего и заходящего солнца не должны попадать в объектив). Следует учитывать направление света фар транспорта, движущегося вблизи зоны просмотра во избежание «засветок» телекамеры.

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

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

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

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

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

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

Вне помещений объекта (на улице) рекомендуется комплектовать телекамеры объективом с автоматической регулировкой диафрагмы.

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

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

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

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

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

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

Конструктивно СОТ должна строиться по модульному принципу и обеспечивать:

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

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

— исключение несанкционированного доступа к элементам управления;

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

3 Общие параметры ТС ИСБ

3.1 Параметры надежности

Параметры надежности ТС ИСБ должны определяться по ГОСТ 27.003-2016 и соответствовать требованиям стандартов на технические средства конкретных видов и ТУ на ТС конкретных типов.

Гарантийный срок эксплуатации ТС ИСБ должен быть не менее 5 лет, за исключением элементов, подлежащих замене в процессе эксплуатации.

Срок службы ТС ИСБ должен составлять не менее 8 лет.

Средняя наработка до отказа невосстанавливаемых (неремонтируемых) ТС ИСБ должна быть не менее 60000 ч, средняя наработка на отказ восстанавливаемых (ремонтируемых) ТС ИСБ должна быть не менее 30000 ч.

Для ТС ИСБ, функционирование которых характеризуется числом коммутационных циклов, средняя наработка до отказа должна быть не менее 1 000 000 рабочих циклов в электрических режимах коммутации, установленных в стандартах на ТС конкретных видов или в ТУ на ТС конкретных типов.

3.2 Параметры электромагнитной совместимости

ТС ИСБ в зависимости от области применения и условий эксплуатации должны обеспечивать помехоустойчивость при воздействии электромагнитных помех следующих степеней жесткости по ГОСТ Р 50009-2000:

— вторая степень — для ТС ИСБ, предназначенных для эксплуатации в закрытых помещениях;

— третья степень — для ТС ИСБ, предназначенных для эксплуатации на открытых площадках и периметрах территорий.

Уровни индустриальных радиопомех, создаваемых ТС ИСБ, при функционировании, должны соответствовать нормам по ГОСТ Р 50009-2000, в зависимости от области применения и условий эксплуатации, установленных в ТУ на ТС конкретных типов.

3.3 Параметры безопасности

ТС ИСБ должны удовлетворять общим требованиям безопасности, установленным в ГОСТ Р 52435-2015, стандартах на ТС конкретных видов и ТУ на ТС конкретных типов.

Конструктивное исполнение ТС ИСБ должно обеспечивать их пожарную безопасность по ГОСТ IEC 60065-2013 в аварийном режиме работы и при нарушении правил эксплуатации.

Значения электрической прочности изоляции ТС ИСБ должны соответствовать требованиям ГОСТ Р 52931-2008, а также стандартов на ТС конкретных видов и ТУ на ТС конкретных типов.

Значения электрического сопротивления изоляции цепей ТС ИСБ должны соответствовать требованиям ГОСТ Р 52931-2008, а также стандартов на ТС конкретных видов, ТУ на ТС конкретных типов.

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

ТС ИСБ, предназначенные для эксплуатации в зонах с взрывоопасной средой, должны соответствовать требованиям ТР ТС 012/2011.

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

Требования устойчивости ТС ИСБ к воздействию климатических и механических факторов должны быть установлены в ТУ на ТС конкретных типов в соответствии с требованиями ГОСТ Р 54455-2011, а также определяться требованиями стандартов на ТС конкретных видов, исходя из области применения и условий эксплуатации ТС.

3.5 Параметры электропитания

Электропитание ТС ИСБ допускается осуществлять от:

— электрической сети систем электроснабжения общего назначения (электрическая сеть);

— ИЭПВР по ГОСТ Р 53560-2009;

— других ТС ИСБ, имеющих специально предназначенные для этого выходы;

— автономных источников электропитания.

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

ТС ИСБ, электропитание которых осуществляется от однофазной электрической сети переменного тока номинальным напряжением 230 В (по ГОСТ 29322-2014). ТС должны сохранять работоспособность при отклонении напряжения электропитания от номинального значения в пределах от минус 20% до плюс 10%.

ТС ИСБ, электропитание которых осуществляется от ИЭПВР, должны сохранять работоспособность при отклонении напряжения электропитания от номинального значения напряжения (12 В или 24 В) на +/- 15%.

ТС ИСБ должны иметь резервное электропитание при пропадании напряжения основного источника электропитания. В качестве резервных источников электропитания может использоваться резервная сеть переменного тока или источники электропитания постоянного тока.

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

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

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

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

В ТС ИСБ рекомендуется применять резервные источники электропитания позволяющие осуществлять удаленный контроль (на АРМ ИСБ) их состояние и основные параметры электропитания.

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

4 Параметры отдельных вспомогательных и дополнительных систем ИСБ

4.1 Параметры системы оповещения

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

На объекте должен быть разработан план оповещения, который в общем случае включает в себя:

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

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

— планы эвакуации;

— систему сигналов оповещения.

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

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

— подачу звуковых, и (или) световых, и (или) речевых сигналов операторам АРМ, дежурным службы безопасности объекта;

— приоритетную подачу сигналов операторам АРМ, дежурным службы безопасности объекта;

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

Сигналы оповещения должны отличаться от сигналов другого назначения.

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

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

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

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

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

4.2 Параметры систем защиты от краж отдельных предметов

Система защиты от краж отдельных предметов должна соответствовать требованиям ГОСТ 32320-2013.

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

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

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

— системы мониторинга предметов повышенной опасности.

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

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

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

— обеспечивать мониторинг предметов повышенной опасности.

Идентификаторы-метки должны:

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

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

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

Электронные идентификаторы-метки, устанавливаемые на упаковку (тару) с предметами повышенной опасности, также должны хранить информацию о количестве, виде, типе, моделях помещенных в нее таких предметах и их индивидуальных номерах.

5 Выбор ИСБ для оборудования объектов

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

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

— обеспечение установленного на объекте режима доступа;

— степень противостояния проникновению на охраняемый объект нарушителей;

— возможность и качество дистанционного контроля за состоянием и изменениями в охраняемой зоне;

— степень противостояния совершению несанкционированных, в том числе криминальных, действий;

— степень достоверности информации о попытках нарушений или несанкционированных действиях;

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

— обеспечение необходимого уровня защиты информационных каналов ИСБ;

— общая организация деятельности служб охраны и безопасности;

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

— оперативность реагирования на попытки совершения нарушений и несанкционированных действий.

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

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

— зонального построения;

— равнопрочности;

— адаптивности.

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

Зональный принцип: ИСБ объекта должна предусматривать возможность создание отдельных охраняемых зон и зон ограниченного доступа.

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

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

Требуемый уровень эффективности защиты должен учитывать особенности критических элементов и критерия «эффективность/стоимость».

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

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

При обследовании объекта необходимо определить:

— характеристики значимости его помещений;

— строительные и архитектурно-планировочные решения;

— материалы исполнения строительных конструкций объекта и отделки внутренних помещений;

— наличие и особенности работы штатных инженерно-технических коммуникаций;

— условия эксплуатации и режимы работы помещений;

— ограничения или расширения права доступа отдельных сотрудников;

— параметры установленных или предполагаемых к установке на данном объекте ТС ИСБ.

По результатам обследования определяются тактико-технические характеристики и структура ИСБ и предоставляются исходные данные для составления технического задания на оборудование объекта.

В техническом задании указывается:

— назначение ИСБ, техническое обоснование и описание системы;

— состав ИСБ;

— размещение компонентов ИСБ;

— условия эксплуатации ТС ИСБ;

— основные технические характеристики ТС ИСБ;

— требования к маскировке и защите ТС ИСБ от вандализма;

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

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

— алгоритм работы ИСБ в аварийных и чрезвычайных ситуациях;

— ПО ИСБ;

— требования к безопасности;

— требования к электропитанию;

— требования к обслуживанию и ремонту ИСБ.

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

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

— возможность максимальной синхронизации всех компонентов ИСБ;

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

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

— стремление к реализации схемотехнических решений с единым состоянием сигнальных выходов ИСБ во всех используемых режимах.

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

— взаимодействии всех ТС ИСБ;

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

— установлении единого вида, способа хранения, регистрации и отображения информации;

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

6 Проектирование ИСБ объекта

Проектирование ИСБ включает следующие этапы работ:

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

— разработка и утверждение технического задания на проектирование (реконструкцию) ИСБ объекта;

— разработка проектной документации.

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

В состав комиссии по обследованию объектов принимаемых под охрану подразделениями вневедомственной охраны войск национальной гвардии Российской Федерации включаются представители подразделений вневедомственной охраны.

Итоги комиссионного обследования оформляются актом. В акте обследования должны быть отражены:

— анализ возможных криминальных угроз;

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

— вид охраны: физическая, техническая, совмещенная (физическая и техническая);

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

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

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

Техническое задание на ИСБ объекта разрабатывается на основе акта анализа уязвимости объекта и является обязательным документом для разработки проектной документации при реконструкции, оснащении ИСБ объекта или при проектировании строительства (реконструкции) объекта в целом.

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

К техническому заданию прилагается:

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

— схема дорог для определения маршрутов движения наряда (пешего или автотранспортного) по территории объекта;

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

Дополнительные данные для проектирования в составе:

— архитектурно-строительные чертежи зданий и сооружений, подлежащих оснащению проектируемой системой (поэтажные планы, разрезы, фасады);

— чертежи коммуникаций (наземных и подземных, пересекающих периметр объекта);

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

— отчеты по геологическим изысканиям.

Проектная документация должна содержать следующий комплект документов:

— техническое задание на разработку проекта;

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

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

— спецификации оборудования и материалов;

— сметную документацию;

— чертежи нестандартизованного оборудования или задания на его разработку;

— эксплуатационную документацию на ИСБ объекта;

— эксплуатационную документацию на технические средства, входящие в состав ИСБ объекта.

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

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

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

7 Ввод в эксплуатацию ИСБ

Прием ИСБ в эксплуатацию производится комиссией, в которую включаются представители:

— заказчика;

— службы охраны объекта;

— монтажной и пусконаладочной организаций;

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

— при необходимости могут быть привлечены специалисты других организаций и ведомств.

При приемке выполненных работ по монтажу и пусконаладке ИСБ комиссия осуществляет:

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

— испытания работоспособности смонтированной ИСБ на соответствие требованиям технического задания.

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

Смонтированная ИСБ считается принятой в эксплуатацию комиссией, если проверкой установлено:

— оборудование объекта техническими средствами ИСБ выполнено в соответствии с проектной документацией;

— испытания работоспособности ИСБ дали положительные результаты.

При эксплуатации ИСБ необходимо проведение ее технического обслуживания в соответствие с требованиями эксплуатационной документации.

Основные задачи технического обслуживания эксплуатации ИСБ:

— обеспечение бесперебойного функционирования;

— контроль технического состояния ИСБ и определение пригодности к дальнейшей эксплуатации;

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

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

— проведение ремонта.

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

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

Примечание — Если измеренное значение напряжения на герметизированных свинцово-кислотных АКБ составляет менее 11,2 В, они бракуются и не подлежат закупке.

— обеспечение соблюдения необходимого температурного режима помещения, используемого для хранения АКБ;

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

— осуществление периодического контроля (не реже одного раза в месяц) электрических параметров АКБ, находящихся на хранении.

Примечание — Если измеренное значение напряжения на герметизированных свинцово-кислотных АКБ составляет менее 11,2 В, следует выполнить их заряд продолжительностью не менее 24 часов (значения зарядного напряжения и предельного зарядного тока в буферном режиме заряда, приводятся в технической документации на АКБ).

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

Примечание — Эксплуатация неисправных или выработавших свой ресурс автономных элементов электропитания, недопустима.

8 Применение ИСБ на взрывоопасных объектах

8.1 Общие положения

К категории опасных производственных объектов относятся объекты, на которых получаются, используются, перерабатываются, образуются, хранятся, транспортируются, уничтожаются следующие опасные вещества:

— воспламеняющиеся;

— окисляющие;

— горючие;

— взрывчатые;

— токсичные вещества.

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

Действующими нормативными документами в области взрывозащищенного оборудования являются серия стандартов ГОСТ Р 30852.9-2002 (МЭК 60079-10:1995), которые соответствуют требованиям международной электротехнической комиссии и европейским стандартам, а также 7 раздел ПУЭ.

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

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

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

I — рудничный метан;

II — остальные промышленные газы и пары.

Технические средства охраны ИСБ относятся к группе II — оборудованию для внутренней и наружной установки (кроме рудничного).

Наибольшее распространение построения взрывозащищенного оборудования технических средств ИСБ получили два вида:

— взрывонепроницаемая оболочка «d»;

— искробезопасная электрическая цепь «i».

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

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

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

Взрывозащищенные ТС ИСБ должны иметь маркировку взрывозащиты, которая обязательно наносится на корпусах.

В маркировку в указанной ниже последовательности входят:

— знак уровня взрывозащиты электрооборудования (2, 1, 0);

— знак «Ex», указывающий на соответствие электрооборудования стандартам на взрывозащищенное электрооборудование. («Ex» — от английского explosion — взрыв);

— знак вида взрывозащиты («d», «p», «q», «o», «e», «i», «m», «n», «s»);

— знак группы или подгруппы электрооборудования (II, IIA, IIB, IIC);

— знак температурного класса электрооборудования (T1, T2, T3, T4, T5, T6).

В маркировке по взрывозащите могут иметь место дополнительные знаки и надписи, например буквы «X» и «U», в соответствии со стандартами на электрооборудование с отдельными видами взрывозащиты.

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

Установлены три уровня взрывозащиты электрооборудования:

— электрооборудование повышенной надежности против взрыва — взрывозащищенное электрооборудование, в котором взрывозащита обеспечивается только в признанном нормальном режиме его работы. Знак уровня — «2Ex»;

— взрывобезопасное электрооборудование — взрывозащищенное электрооборудование, в котором взрывозащита обеспечивается как при нормальном режиме работы, так и при признанных вероятных повреждениях, определяемых условиями эксплуатации, кроме повреждений средств взрывозащиты. Знак уровня — «1Ex»;

— особо взрывобезопасное электрооборудование — взрывозащищенное электрооборудование, в котором по отношению к взрывобезопасному электрооборудованию приняты дополнительные средства взрывозащиты, предусмотренные стандартами на виды взрывозащиты. Знак уровня — «0Ex».

Маркировка вида взрывозащиты:

— взрывонепроницаемая оболочка маркируется буквой «d»;

— искробезопасная электрическая цепь маркируется буквой «i».

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

Таблица 8.1 — Подгруппы электрооборудования группы II

Знак группы электрооборудования	Знак подгруппы электрооборудования	Категория взрывоопасной смеси, для которой электрооборудование является взрывозащищенным
II	—	IIA, IIB и IIC
	IIA	IIA
	IIB	IIA и IIB
	IIC	IIA, IIB и IIC

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

Электрооборудование, промаркированное как IIB, пригодно также для применения там, где требуется электрооборудование подгруппы IIA. Подобным образом, электрооборудование, имеющее маркировку IIC, пригодно также для применения там, где требуется электрооборудование подгруппы IIA или IIB.

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

Таблица 8.2 — Температурные классы электрооборудования группы II

Знак температурного класса электрооборудования	Предельная температура, °C	Группа взрывоопасной смеси, для которой электрооборудование является взрывозащищенным
T1	450	T1
T2	300	T1, T2
T3	200	T1 — T3
T4	135	T1 — T4
T5	100	T1 — T5
T6	85	T1 — T6

Для того чтобы установить, какой уровень взрывозащиты должны иметь ТС ИСБ необходимо определить класс взрывоопасной зоны. Согласно п. 7.3.38 ПУЭ, класс взрывоопасной зоны должен определяться технологами совместно с электриками проектной или эксплуатирующей организации.

Классификация взрывоопасных зон определена в пп. 7.3.40 — 7.3.46 ПУЭ и зависит от концентрации, химических свойств огнеопасных веществ и их агрегатного состояния (газ, пар, жидкость или пыль). Класс взрывоопасной зоны также зависит от того, определено ли присутствие огнеопасных веществ нормальным режимом работы, или это возможно только в результате аварий или неисправностей.

Исходя из класса взрывоопасной зоны, в которой должны устанавливаться ТС ИСБ, определяется требуемый уровень взрывозащиты оболочки или искробезопасной электрической цепи. Различие между этими уровнями заключаются в степени надежности этой цепи. Так, цепи уровня «ia» не должны вызывать воспламенения взрывоопасной смеси даже при двух повреждениях, цепи уровня «ib» при одном повреждения, а цепи уровня «ic» не допускают таких повреждений.

С видом взрывозащиты «взрывонепроницаемая оболочка» выпускается извещатель для работы в подсистеме СОС — ИО 209-22 «СПЭК-11», уровень взрывозащиты «взрывобезопасный», маркировка взрывозащиты 1ExdIIBT5X. Внешний вид извещателя ИО 209-22 «СПЭК-11» приведен на рисунке 8.1.

Рисунок 8.1 — Извещатель ИО 209-22 «СПЭК-11»

Этот извещатель предназначен для применения в неагрессивных средах во взрывоопасных зонах помещений классов 1 или 2 по ГОСТ Р 30852.9-2002 (МЭК 60079-10:1995) (классы B-Iа, B-Iб, B-Iг по гл. 7.3 ПУЭ).

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

Кронштейн для юстировки включен в комплект поставки извещателя.

Технические характеристики извещателя ИО 209-22 «СПЭК-11» представлены в таблице 8.3.

Таблица 8.3

Характеристика	Значение
Дальность действия, м	125
при коэффициенте запаса	25
Напряжение питания, В	от 10 до 27
Чувствительность, мс	130
Длительность извещения «Тревога», с, не менее	2
Диапазон рабочих температур, °C	От минус 40
до плюс 35
Габариты БИ, БП, мм (без учета кронштейна и кабеля в металлорукаве)	155 x 95 x 85
Масса, кг	5

К блокам излучателя и приемника извещателя присоединен кабель в металлорукаве длиной 10 м. Все соединения производятся вне взрывоопасной зоны, во взрывоопасной зоне устанавливаются только указанные блоки.

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

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

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

Пример оборудования объекта с взрывоопасными зонами приведен на рисунке 8.2

ПЦН — пульт централизованного наблюдения;

БПС — блок питания сетевой;

БПР — блок питания резервный;

БОС — блок обработки сигналов;

БИЗ — блок искрозащиты;

ИТ — извещатель тревожный

ИО — извещатели охранный.

Рисунок 8.2 — Оборудование объекта с взрывоопасными зонами

8.2 СОС для организации охраны взрывоопасных зон помещений с неагрессивной средой

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

В состав подсистемы входят:

— блок расширения шлейфов сигнализации «БРШС-Ex», обеспечивающий питание и прием извещений от извещателей, установленных во взрывоопасной зоне по искробезопасным шлейфам;

— извещатель охранный оптико-электронный объемный ИО 409-40 «Фотон-18»;

— извещатель охранный оптико-электронный линейный ИО 209-30 «Фотон-18А»;

— извещатель охранный оптико-электронный поверхностный ИО 30918 «Фотон-18Б»;

— извещатель охранный оптико-электронный поверхностный ИО 30921 «Фотон-Ш-Ex»;

— извещатель охранный поверхностный звуковой ИО 329-9 «Стекло-Ex»;

— извещатель охранный поверхностный вибрационный ИО 313-6 «Шорох-Ex»;

— извещатель охранный точечный магнитоконтактный ИО 102-33 «МК-Ex»;

— сигнализатор тревожный газовый «СТГ-Ex»;

— сигнализатор тревожный затопления «СТЗ-Ex».

Внешний вид блока расширения шлейфов сигнализации «БРШС-Ex» приведен на рисунке 8.3.

Рисунок 8.3

Блок устанавливается вне взрывоопасной зоны и обеспечивает:

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

— электропитание извещателей напряжением 12 В по искробезопасным цепям;

— отключение электропитания ШС, находящихся в состоянии «КЗ»;

— имитостойкость ШС в составе системы;

— контроль вскрытия корпуса.

Блок «БРШС-Ex» имеет два исполнения в зависимости от номинальной нагрузочной мощности цепей электропитания. Электропитание блока «БРШС-Ex» осуществляется от резервированного источника электропитания номинальным напряжением 12 В («Ладога БП-А»).

Технические характеристики блока «БРШС-Ex» представлены в таблице 8.4.

Таблица 8.4

Характеристика	Значение
Маркировка взрывозащиты	[Exib]IIBX
Напряжение питания, В	от 10,5 до 14
Ток потребления, мА не более (при отсутствии подключенных извещателей к клеммам питания)	150
Параметры цепей электропитания — номинальное выходное напряжение, В	12
— номинальный выходной ток, мА (исп. 1)	625
— номинальный выходной ток, мА (исп. 2)	200
Диапазон рабочих температур, °C	от плюс 1 до плюс 50
Габариты, мм	230 x 177 x 50
Масса, кг	1,5

Извещатели охранные оптико-электронные ИО 409-40 «Фотон-18», ИО 209-30 «Фотон-18А», ИО 309-18 «Фотон-18Б»

Внешний вид извещателей охранных оптико-электронных ИО 409-40 «Фотон-18», ИО 209-30 «Фотон-18А», ИО 309-18 «Фотон-18Б» приведен на рисунке 8.4.

Рисунок 8.4

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

Особенность — три зоны обнаружения формируются тремя типами линз Френеля:

— объемная — ИО 409-40 «Фотон-18»;

— линейная — ИО 209-30 «Фотон-18А»;

— поверхностная — ИО 309-18 «Фотон-18Б».

Технические характеристики извещателей ИО 409-40 «Фотон-18», ИО 209-30 «Фотон-18А», ИО 309-18 «Фотон-18Б» представлены в таблице 8.5.

Таблица 8.5

Характеристика	Значение
Маркировка взрывозащиты	1ExibIIBT6X
Напряжение питания, В	от 9 до 14
Ток потребления, мА	не более 20
Дальность действия (зона обнаружения), м
ИО 409-40 «Фотон-18»	12 (объемная)
ИО 209-30 «Фотон-18А»	20 (линейная)
ИО 309-18 «Фотон-18Б»	15 (поверхностная)
Габаритные размеры, мм	105 x 75 x 56
Масса, кг	не более 0,1
Степень защиты оболочки	IP41
Диапазон рабочих температур, °C	от минус 30 до плюс 50

Извещатель охранный поверхностный оптико-электронный ИО 309-21 «Фотон-Ш-Ex»

Внешний вид извещателя поверхностного оптико-электронного ИО 309-21 «Фотон-Ш-Ex» приведен на рисунке 8.5.

Рисунок 8.5

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

Особенности:

— сплошная зона обнаружения типа «занавес»,

— рекомендуемая высота установки от 2,5 до 5 м.

Технические характеристики извещателя ИО 309-21 «Фотон-Ш-Ex» представлены в таблице 8.6.

Таблица 8.6

Характеристика	Значение
Маркировка взрывозащиты	1ExibIIBT6X
Напряжение питания, В	от 9 до 14
Ток потребления, мА	не более 20
Габаритные размеры, мм	91 x 52 x 56
Масса, кг	не более 0,2
Степень защиты оболочки	IP41
Диапазон рабочих температур, °C	от минус 30 до плюс 50

Извещатель охранный поверхностный звуковой ИО 329-9 «Стекло-Ex»

Внешний вид извещателя охранного поверхностного звукового ИО 329-9 «Стекло-Ex» приведен на рисунке 8.6.

Рисунок 8.6

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

Особенности:

— возможность регулировки чувствительности;

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

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

Технические характеристики извещателя ИО 329-9 «Стекло-Ex» представлены в таблице 8.7.

Таблица 8.7

Характеристика	Значение
Маркировка взрывозащиты	1ExibIIbT6X
Напряжение питания, В	от 9 до 14
Ток потребления, мА	30

Продолжение таблицы 8.7

Характеристика	Значение
Максимальная дальность действия, м	6
Диапазон рабочих температур, °C	от минус 20 до плюс 45
Габариты, мм	80 x 80 x 35
Масса, кг не более	0,12

Извещатель охранный поверхностный ИО 313-6 «Шорох-Ex»

Внешний вид извещателя охранного поверхностного вибрационного ИО 313-6 «Шорох-Ex» приведен на рисунке 8.7.

Рисунок 8.7

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

Особенности:

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

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

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

— световая индикация состояния извещателя и помеховых вибраций охраняемой конструкции.

Технические характеристики извещателя ИО 313-6 «Шорох-Ex» представлены в таблице 8.8.

Таблица 8.8

Характеристика	Значение
Маркировка взрывозащиты	1ExibIIBT6X
Напряжение питания, В	от 9 до 14
Ток потребления, мА	20
Диапазон рабочих температур, °C	от минус 30 до плюс 50
Габариты, мм	105 x 45 x 35
Масса, кг не более	0,3

Извещатель охранный точечный магнитоконтактный ИО 102-33 «МК-Ex»

Внешний вид извещателя охранного точечного магнитоконтактного ИО 102-33 «МК-Ex» приведен на рисунке 8.8.

Рисунок 8.8

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

Технические характеристики извещателя ИО 102-33 «МК-Ex» представлены в таблице 8.9.

Таблица 8.9

Характеристика	Значение
Маркировка взрывозащиты	1ExibIIBT6X
Ток коммутации, мА	от 0,1 до 100
Напряжение коммутации, В	от 0,1 до 72
Масса, кг:
— магнитоуправляемого датчика	0,23
— задающего элемента	0,15
Степень защиты оболочки	IP44
Диапазон рабочих температур, °C	от минус 10 до плюс 50
Габариты, мм	105 x 45 x 35

Сигнализатор тревожный газовый «СТГ-Ex»

Внешний вид сигнализатора тревожного газового «СТГ-Ex» приведен на рисунке 8.9.

Рисунок 8.9

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

Технические характеристики сигнализатора «СТГ-Ex» представлены в таблице 8.10.

Таблица 8.10

Характеристика	Значение
Маркировка взрывозащиты	[Exib]BT6X
Напряжение питания, В	от 10 до 13
Ток потребления, мА	не более 50
Габаритные размеры, мм	80 x 80 x 35
Масса, кг не более	0,1
Степень защиты оболочки	IP30
Диапазон рабочих температур, °C	от минус 30 до плюс 50

Сигнализатор тревожный затопления «СТЗ-Ex»

Внешний вид сигнализатора тревожного затопления «СТЗ-Ex» приведен на рисунке 8.10.

Рисунок 8.10

Сигнализатор тревожный затопления «СТЗ-Ex» предназначен для обнаружения утечек воды из водопроводов, используемых при водоснабжении и отоплении зданий и помещений при индивидуальной и многоэтажной застройке или в котельных.

В состав сигнализатора «СТЗ-Ex» входит блок обработки сигналов и до трех датчиков затопления.

Технические характеристики сигнализатора «СТЗ-Ex» представлены в таблице 8.11.

Таблица 8.11

Характеристика	Значение
Маркировка взрывозащиты	[Exib]BT6X
Напряжение питания, В	от 9 до 14
Ток потребления, мА не более	10
Габаритные размеры, мм
блок обработки сигналов	80 x 80 x 35
датчик затопления	35 x 15 x 15

Продолжение таблицы 8.11

Характеристика	Значение
Масса, кг не более
блок обработки сигналов	0,08
датчик затопления	0,007
Степень защиты оболочки	IP40
Диапазон рабочих температур, °C	от минус 30 до плюс 50

8.3 Специальные требования при установке технических средств ИСБ во взрывоопасных зонах

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

Допускается установка ТС ИСБ во взрывоопасных зонах любого класса при условии, что уровень их взрывозащиты или степень защиты являются более высокими.

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

Не допускается устанавливать ТС ИСБ с обнаруженными дефектами.

Во взрывоопасных зонах классов B-1 и B-1а должны применяться провода и кабеля с медными жилами. Допускается применение проводов и кабелей с алюминиевыми жилами во взрывоопасных зонах классов B-16, B-1г, B-II, B-IIа.

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

— провода с резиновой, поливинилхлоридной изоляцией;

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

Не допускается применение кабелей:

— с алюминиевой оболочкой во взрывоопасных зонах классов B-1 и B-1а;

— полиэтиленовой изоляцией и оболочкой во взрывоопасных зонах любого класса.

Способы прокладки кабелей и проводов во взрывоопасных зонах приводится в таблице 8.12.

Таблица 8.12

Кабели и провода	Способы прокладки	Класс взрывоопасной зоны
Бронированные кабели	Открыто — по стенам и строительным конструкциям на скобах и кабельных конструкциях; в коробах, лотках, на тросах, кабельных и технологических эстакадах; в каналах. Скрыто — в земле (траншеях), в блоках.	В зонах любого класса

Продолжение таблицы 8.12

Кабели и провода	Способы прокладки	Класс взрывоопасной зоны
Небронированные кабели в резиновой поливинилхлоридной и металлической оболочках	Открыто — при отсутствии механических и химических воздействий; по стенам и строительным конструкциям на скобах и кабельных конструкциях; в лотках, на тросах.	B-1а, B-16. B-1г, B-IIа (кроме силовых сетей и вторичных цепей до 1 кВ)
В каналах пылеуплотненных (например, покрытых асфальтом) или засыпанных песком.	B-II, B-IIа B-1а, B-16, B-1г
Открыто — в коробах. Открыто и скрыто — в стальных водогазопроводных трубах	В зонах любого класса
Изолированные провода	То же	То же

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

— искробезопасные цепи должны отделяться от других цепей с соблюдением требований ГОСТ 227825-78, использование одного кабеля для искробезопасных и искроопасных цепей не допускается;

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

— провода искробезопасных цепей должны быть защищены от наводок нарушающих их искробезопасность.

Проходы кабелей сквозь внутренние стены и междуэтажные перекрытия в зонах классов B-1, B-1а и B-II следует выполнять в отрезках водогазопроводных труб. Зазоры между трубами и кабелями должны быть заделаны уплотнительным составом на глубину 100 — 200 мм от конца трубы, с общей толщиной, обеспечивающей огнестойкость строительных конструкций.

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

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

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

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

Вводы кабелей в ТС ИСБ должны выполняться при помощи вводных устройств. Места вводов должны быть уплотнены. Не допускается ввод защитных электроприводов в технические средства, имеющие вводы только для кабелей.

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

Через взрывоопасные зоны любого класса, а также на расстоянии менее 5 м по горизонтали и вертикали от взрывоопасной зоны не допускается прокладывать транзитные электропроводки и кабельные линии всех напряжений. Допускается их прокладка в трубах, в закрытых коробах, в полах.

9 PSIM (ПСИМ)-системы

На сегодняшний день для осуществления охраны объектов применяется широкий спектр различных систем безопасности, входящих в состав ИСБ. Количество извещателей, видеокамер, датчиков различных дополнительных систем жизнеобеспечения неуклонно растет. В силу этого, для обработки поступающей информации и своевременного реагирования на возникающие угрозы безопасности объектов, требуется привлечение значительных материально-технических и человеческих ресурсов. При этом, последней инстанцией принятия решений о приоритете реагирования на одновременно возникшие угрозы безопасности, является оператор АРМ ИСБ, что из-за влияния «человеческого фактора», далеко не всегда приводи к принятию оптимальных решений. Одним из перспективных путей преодоления данной проблемы является использование технологии машинной (интеллектуальной) обработки данных с предоставлением оператору АРМ ИСБ возможных сценариев принятия решений, а также аппаратно-программная интеграция имеющихся (разнородных) систем безопасности.

Данная технология реализуется с помощью применения интеллектуальных интегрированных цифровых платформ, собирающих и обрабатывающих информацию от различных систем обеспечения безопасности. Такие платформы называются PSIM (ПСИМ) — системы (от английского Physical security information management — «управление информацией о физической безопасности») — категория программного обеспечения, предоставляющая аппаратно-программный комплекс для интеграции нескольких независимо функционирующих систем, программных продуктов и ТС, а также управления ими через единый пользовательский интерфейс.

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

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

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

К основным составляющим ПСИМ-систем следует отнести несколько логических модулей:

— интеграция;

— аналитика;

— управление.

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

К основным функциям ПСИМ-систем следует отнести:

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

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

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

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

— между людьми;

— между оборудованием или машинами;

— перекрестного взаимодействия на уровне «человек — машина» и «машина — человек». ПСИМ-системы призваны, моделировать и прогнозировать случаи наступления того или иного события, действовать проактивно, а также реагировать в соответствии с внутренними регламентами и нормативами.

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

— единая информационная среда;

— единая система тревог;

— единая система оповещения и помощь в принятии эффективных решений;

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

— единый формат уведомлений и назначения задач ответственному лицу;

— единый подход к выполнению регламентированных задач и многоуровневая архитектура.

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

Также в ПСИМ-системах реализуется:

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

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

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

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

ГОСТ 27.003-2016 Надежность в технике (ССНТ). Состав и общие правила задания требований по надежности.

ГОСТ 28195-89 Оценка качества программных средств. Общие положения.

ГОСТ 29322-2014 (IEC 60038:2009) Напряжения стандартные.

ГОСТ 32320-2013 Технические средства и системы защиты от краж отдельных предметов. Общие технические требования и методы испытаний.

ГОСТ 52436-2005 Приборы приемно-контрольные охранной и охранно-пожарной сигнализации. Классификация. Общие технические требования и методы испытаний.

ГОСТ 60065-2013 Аудио-, видео- и аналогичная электронная аппаратура. Требования безопасности.

ГОСТ 22782.5-78 Электрооборудование взрывозащищенное с видом взрывозащиты «Искробезопасная электрическая цепь». Технические требования и методы испытаний.

ГОСТ Р 50009-2000 Совместимость технических средств электромагнитная. Технические средства охранной сигнализации. Требования и методы испытаний.

ГОСТ Р 51241-2008 Средства и системы контроля и управления доступом. Классификация. Общие технические требования. Методы испытаний.

ГОСТ Р 30852.9-2002 Электрооборудование взрывозащищенное. Часть 10. Классификация взрывоопасных зон.

ГОСТ Р 51558-2014 Средства и системы охранные телевизионные. Классификация. Общие технические требования. Методы испытаний.

ГОСТ Р 52435-2015 Технические средства охранной сигнализации. Классификация. Общие технические требования и методы испытаний.

ГОСТ Р 52551-2016 Системы охраны и безопасности. Термины и определения.

ГОСТ Р 52931-2008 Приборы контроля и регулирования технологических процессов. Общие технические условия.

ГОСТ Р 53195.1-2008 Безопасность функциональная связанных с безопасностью зданий и сооружений систем. Часть 1. Основные положения.

ГОСТ Р 53560-2009 Системы тревожной сигнализации. Источники электропитания. Классификация. Общие технические требования. Методы испытаний.

ГОСТ Р 54455-2011 (МЭК 62599-1:2010) Системы охранной сигнализации. Методы испытаний на устойчивость к внешним воздействующим факторам.

ГОСТ Р 54831-2011 Системы контроля и управления доступом. Устройства преграждающие управляемые. Общие технические требования. Методы испытаний.

ГОСТ Р 57674-2017 Интегрированные системы безопасности. Общие положения.

Правила устройства электроустановок (ПУЭ) 7-е издание (утв. приказом Минэнерго РФ от 8 июля 2002 г. N 204).

ТР ТС 012/2011 Технический регламент таможенного союза «О безопасности оборудования для работы во взрывоопасных средах».

Список технических средств безопасности, удовлетворяющих «Единым требованиям к системам передачи извещений, объектовым техническим средствам охраны и охранным сигнально-противоугонным устройствам автотранспортных средств, предназначенным для применения в подразделениях вневедомственной охраны войск национальной гвардии Российской Федерации» (рекомендован решением заседания Технического совета ГУВО Росгвардии).

Р 78.36.002-2010 Рекомендации «Выбор и применение систем охранных телевизионных».

Р 78.36.019-2012 «Рекомендации по организации централизованной охраны при проведении операторами связи модернизации сетей передачи данных, в том числе с применением PON-технологий».

Р 78.36.022-2012 Методическое пособие «Применение радиоволновых и комбинированных извещателей с целью повышения обнаруживающей способности и помехозащищенности».

Р 78.36.027-2012 «Рекомендации по применению тепловизионного оборудования в системах охранного телевидения».

Р 78.36.030-2013 Методические рекомендации «Применение программных средств анализа видеоизображения в системах охранного телевидения в целях повышения антитеррористической защищенности ПЦО подразделений вневедомственной охраны».

Р 78.36.036-2013 «Методическое пособие по выбору и применению пассивных оптико-электронных инфракрасных извещателей».

Р 78.36.042-2014 «Рекомендации по использованию комплекта оборудования для фиксации и передачи видеоинформации с охраняемого объекта на ПЦО».

Р 78.36.044-2014 «Методическое пособие по выбору и применению охранных поверхностных звуковых извещателей для блокировки остекленных конструкций закрытых помещений».

ТП 78.36.002-2014 Типовой рабочий проект «Система охранно-тревожной сигнализации административное здание».

ТП 78.36.004-2014 Типовой рабочий проект «Система охранного телевидения».

ТП 78.36.005-2014 Типовой рабочий проект «Система контроля и управления доступом. Административное здание».

Р 78.36.049-2015 Рекомендации «Применение оборудования охранных телевизионных систем в условиях ограниченной видимости или других дестабилизирующих факторов».

Р 78.36.050-2015 Методические рекомендации «Выбор и применение активных оптико-электронных извещателей для блокировки внутренних и внешних периметров, дверей, окон, витрин и подступов к отдельным предметам».

Р 78.36.051-2015 Методические рекомендации «Типовые проектные решения оснащения техническими средствами охраны объектов различных категорий, охраняемых подразделениями вневедомственной охраны полиции».

Р 78.36.052-2015 Методические рекомендации «Типовые проектные решения оснащения техническими средствами охраны объектов органов внутренних дел Российской Федерации, отнесенных к первой категории».

Р 78.36.053-2015 Методические рекомендации «Применение оборудования с использованием защищенных каналов передачи данных, представляемых операторами сотовой связи».

Р 78.36.058-2016 Методические рекомендации «Оценка трудозатрат работ по проектированию, монтажу и пусконаладке технических средств и систем противокриминальной защиты».

Р 064-2017 Методические рекомендации «Выбор и применение технических средств и систем контроля и управления доступом».

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

Р 069-2017 «Рекомендации по выбору и применению средств обнаружения проникновения в зависимости от степени важности и опасности охраняемых объектов».

Р 071-2017 Рекомендации «Технические средства систем безопасности объектов. Обозначения условные графические элементов технических средств охраны, систем контроля и управления доступом, систем охранного телевидения».

Р 075-2018 Методические рекомендации «Участие подразделений вневедомственной охраны войск национальной гвардии Российской Федерации в мероприятиях по антитеррористической защищенности объектов различной ведомственной принадлежности».

Р 076-2018 Методические рекомендации «Ложные срабатывания технических средств охранной сигнализации и методы борьбы с ними».

Р 081-2019 Методические рекомендации «Выбор и применение технических средств охраны для защиты объектов культурного наследия Российской Федерации от преступных посягательств».

Р 083-2019 Методические рекомендации «Нормы и правила проектирования систем безопасности на объектах, охраняемых (принимаемых под охрану) подразделениями вневедомственной охраны».

Р 084-2019 «Требования к функциональным свойствам технических средств безопасности на объектах, подлежащих обязательной охране войсками национальной гвардии Российской Федерации, и правила их обязательного подтверждения соответствия установленным техническим требованиям».

Р 085-2019 Методические рекомендации «Правила производства монтажа и технического обслуживания технических средств безопасности на объектах, охраняемых (принимаемых под охрану) подразделениями вневедомственной охраны войск национальной гвардии Российской Федерации, а также порядок контроля за их проведением».

Примечание — Указанные информационные материалы представлены на официальном сайте ФКУ «НИЦ «Охрана» Росгвардии — http://www.nicohrana.ru.

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

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

Какими бывают корпоративные угрозы

Корпоративные угрозы можно разделить на несколько видов (таблица 1).

Таблица 1. Виды корпоративных угроз

Виды угроз	Источники угроз
В зависимости от места возникновения
Внутренние угрозы	Некачественный отбор персонала. Нарушение сотрудниками правил трудового распорядка. Действия сотрудников, причиняющие предприятию материальный и (или) репарационный ущерб.
Внешние угрозы	Действия рейдерских компаний или отдельных лиц, направленные на захват управления или имущества компании. Действия конкурентов, направленные на подрыв репутации компании, кражу интеллектуальной собственности, коммерческой тайны. Экономический террор по отношению к компании. Поступки физических лиц, вызванные личной неприязнью к компании, её руководству или персоналу, нацеленные на подрыв репутации компании и (или) порчу имущества. Незаконные действия госорганов и силовых структур.
В зависимости от фактора воздействия
Экономические	Объективные	Возникают по причинам экономических кризисов, инфляции, санкций.
Преднамеренные	Могут возникнуть ввиду мошеннических действий, недобросовестной конкуренции, демпинга, промышленного шпионажа.
Юридические	Целенаправленные	Заведомо неправильное оформление документов.
Субъективные	Возникают из-за правовой неосведомлённости.
Информационные	Преднамеренные	Связаны с разглашением, использованием, искажением или уничтожением конфиденциальной информации, порчей используемого для приёма и хранения данных оборудования.
Непреднамеренные	Ошибки при разработке ПО, халатность сотрудников, отказ техники
Физические	Непреднамеренные	Связаны техногенными авариями и природными явлениями.
Преднамеренные	Взломы, кражи, непреднамеренное проникновение на территорию и т.п.

Кроме этого, угрозы можно классифицировать по уровню допустимости — на реальные и потенциальные.

Справка! Потенциальная угроза — это опасность «в зачатке», формирование предпосылок к возможному нанесению вреда. Реальные угрозы представляют собой окончательно сформировавшееся явление, когда для нанесения вреда недостаёт одного или нескольких условий. Вероятность реальной угрозы можно подсчитать исходя из теистических данных, с помощью экспертных методов, методами группового SWOT-анализа.

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

Как обеспечить безопасность организации: 10 принципов

Защитным «куполом» от внешних и внутренних угроз для компании станет комплекс мер по обеспечению корпоративной безопасности.

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

Итак, система безопасности должна быть:

1. Комплексной. Руководство должно учесть все потенциальные угрозы.
2. Целесообразной. Расходы на безопасность нужно сопоставить с размерами потенциального ущерба
3. Постоянной. Цикл защиты должны работать непрерывно по цепочке: планирование — тестирование — внедрение — совершенствование — планирование.
4. Своевременной. Каждое мероприятие по созданию безопасности должно быть направлено на предупреждение возможных угроз и содержать алгоритмы по недопущению посягательств на ценности компании.
5. Специализированной. Для работы с системой следует использовать специально обученных и подготовленных специалистов.
6. Заменяемой. Способы защиты рекомендуется дублировать, чтобы иметь запасной вариант в случае выпадения одного из звеньев системы безопасности.
7. Централизованной. Система безопасности компании должна функционировать в соответствии с общими утверждёнными принципами и контролироваться руководителем организации.
8. Плановой. Защита должна укрепляться в соответствии с планами, разработанными для каждого подразделения, отдела, отдельных сотрудников компании.
9. Законной. Безопасность компании должна обеспечиваться в рамках действующего законодательства.
10. Прогрессивной. Средства и меры защиты нужно постоянно совершенствовать и дополнять, следить за выходом поправок в законах и методиках, техническими новинками.

Строим систему безопасности: с чего начать

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

Далее можно придерживаться несложного пошагового алгоритма

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

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

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

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

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

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

4. И снова — аудит. Но на этот раз будем проверять на прочность саму систему безопасности. Такие проверки бывают двух видов — внутренние и внешние (таблица 2)

Таблица 2. Особенности аудита службы безопасности

Виды аудита	Цели аудита	Объекты аудита
Внутренний аудит	Проводится для выявления и исправления ошибок службы безопасности и защиты от потенциальных рисков, вызванных некомпетентностью работников службы, их недостаточным взаимодействием с другими подразделениями.	Проверяют: эпизоды биографии и квалификацию работников; степень профессиональной подготовки; методы сотрудничества службы безопасности с другими подразделениями; виды и качество профессиональных мероприятий службы безопасности.
Внешний аудит	Комплекс мер направлен на проверку эффективности реакции на угрозы извне.	Проверяют: эффективность реагирования на вторжения в зону охраняемой территории; оперативность обнаружения «жучков» и других возможных средств слежения; режимы денежных перевозок и перемещений товаров; внеслужебные связи сотрудников (как они могут влиять на отношение сотрудника службы безопасности к работе); функциональность технических систем по контролю доступа.

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

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

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

Пару слов в защиту «бумажной» безопасности

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

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

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

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

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

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

Пара уточнений

Для начала, чтобы исключить лишние вопросы и домыслы считаем необходимым прояснить несколько моментов.

1. В статье мы рассмотрим только внутренние организационно-распорядительные документы (далее – ОРД) по защите информации. Проектные, аттестационные и прочие документы рассматриваться не будут.
2. Модель угроз тоже рассматривать не будем, хотя ее шаблон и есть здесь. Разработка модели угроз это отдельная история. Напишите в комментариях – нужен ли на Хабре мануал по разработке модели угроз?
3. В статье будем опираться на наш комплект шаблонов. Он не является каким-то стандартом или общепринятым набором. В этом комплекте отражен сугубо наш подход к разработке ОРД. Поскольку законодательство зачастую не предписывает в этом плане ничего конкретного, у вас может быть свое мнение насчет комплектности и содержания документов и это нормально!
4. В шаблонах могут быть ошибки и опечатки. Мы сами постоянно улучшаем и дорабатываем их.
5. В контексте выполнения требований будет затронута в основном тематика персональных данных (152-ФЗ и подзаконные акты) и государственных информационных систем (17 приказ ФСТЭК). Помимо этого есть еще отдельная история с финансовыми организациями (требования ЦБ РФ) и различные стандарты (ISO 2700х и другие) – их мы рассматривать здесь не будем.

Комплектность документов

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

Для примера приведем часть 2 статьи 19 закона №152-ФЗ «О персональных данных». Обычным текстом будет текст закона, курсивом – примечания автора.

2. Обеспечение безопасности персональных данных достигается, в частности:

1) определением угроз безопасности персональных данных при их обработке в информационных системах персональных данных; (нужна модель угроз)

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

3) применением прошедших в установленном порядке процедуру оценки соответствия средств защиты информации;

4) оценкой эффективности принимаемых мер по обеспечению безопасности персональных данных до ввода в эксплуатацию информационной системы персональных данных;

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

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

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

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

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

Данным примером нам хотелось показать разницу: как написан закон и что по факту он от нас требует. Здесь мы не видим прямого требования «оператор должен разработать модель угроз», но эта необходимость все равно следует из текста 152-ФЗ, так как выполнение любого требования подтверждается документально.

Более конкретно о комплектности и содержании ОРД нам говорит ФСТЭК. В 2014 году этот регулятор выпустил методический документ «Меры защиты информации в государственных информационных системах». Документ без сарказма отличный, если вам было что-то непонятно по порядку выполнения мер 17-го, 21-го или другого приказа ФСТЭК (да, хоть документ и предназначен для ГИС, но меры по большей части у ФСТЭКа совпадают), обратитесь к этому документу, возможно, станет сильно понятнее.

Так вот, в этом документе ФСТЭК более расширенно расписывает меры по обеспечению безопасности информации и очень часто можно встретить такой текст:

Правила и процедуры идентификации и аутентификации пользователей регламентируются в организационно-распорядительных документах по защите информации. (ИАФ.1)

Правила и процедуры управления учетными записями пользователей регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.1)

Правила и процедуры управления информационными потоками регламентируются в организационно-распорядительных документах оператора по защите информации. (УПД.3)

Отлично, уже что-то, но этих правил и процедур целый вагон.

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

Главная мысль этого раздела – есть гора требований в законодательстве по защите информации, выполнение многих из них нужно подтвердить документально. Делать ли под каждое требование отдельный документ или слить все в одну большую «Политику ИБ» — решать каждому. Все дополнительное, что нам нужно в документах прописать не по требованиям, а исходя из практической необходимости, дописываем без каких-либо проблем.

Кстати, обратите внимание, что в таблице и в самих документах некоторые разделы или абзацы помечены «К1» или «К2+». Это означает что раздел или абзац необходим только для информационных систем 2 класса и выше или для первого (максимального класса). Все что не помечено – выполняется во всех государственных информационных системах и ИСПДн.

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

Наши шаблоны разбиты на 4 папки:

Общее – документы, которые необходимо разработать для всех систем (по мере применимости), будь то ИСПДн, ГИС, АСУ ТП или объект КИИ.

Только ГИС – документы для государственных информационных систем или муниципальных информационных систем, тут только уникальные документы, нужные для ГИС и МИС.

ПДн – документы по защите персональных данных и во исполнение законодательства по защите персональных данных. Если, например, у нас ГИС, в которой обрабатываются персональные данные, то мы должны сделать документы из всех папок.

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

Рассмотрим далее подробнее документы, откуда они появились и какие требования выполняют.

Общие

01 Приказ о назначении ответственных лиц и инструкции этим лицам

Этим приказом назначаются: ответственный за организацию обработки персональных данных и администратор безопасности.

Необходимость назначения первого обусловлена статьей 18.1 федерального закона:

1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:

1) назначение оператором, являющимся юридическим лицом, ответственного за организацию обработки персональных данных;

Администратор безопасности – необходимость этого товарища обусловлена например пунктом 9 приказа ФСТЭК №17:

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

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

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

02 Приказ о назначении группы реагирования на инциденты информационной безопасности (ГРИИБ) и инструкция по реагированию

Сокращение ГРИИБ хоть и немного смешное, но вполне себе официальное, введено ГОСТ Р ИСО/МЭК ТО 18044-2007 «Информационная технология. Методы и средства обеспечения безопасности. Менеджмент инцидентов информационной безопасности».

Необходимость документов необходима целым рядом нормативно-правовых документов. Например, той же статьей 19 закона «О персональных данных». Но более подробно реагирование на инциденты раскрывается в приказах ФСТЭК.

Приказ ФСТЭК №17:

18.2. В ходе выявления инцидентов и реагирования на них осуществляются:

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

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

03 Инструкция пользователя

Основное правовое обоснование необходимости такой инструкции это все места в законодательстве, где сказано про инструктаж пользователей по вопросам информационной безопасности. Например, часть 1 статьи 18.1 закона «О персональных данных»:

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

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

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

05 Политика информационной безопасности

Наверное, один из наиболее объемных документов из всего набора. Помните выше мы писали о документе «Меры защиты информации в ГИС» и про большое количество «правил и процедур», которые необходимо прописать в ОРД? Собственно «Политика ИБ» это и есть, по сути, сборник всех таких правил и процедур.

Тут, пожалуй, стоит остановиться на слове «Политика». Нам часто говорят, что у нас «Политика» слишком целенаправленная, а на самом деле документ с таким названием должен быть более абстрактным и высокоуровневым. Может и так, но у нас как у безопасников все-таки в первую очередь с техническим бэкграундом слово «Политика» ассоциируется, например, с групповыми политиками домена, что уже в свою очередь ассоциируется с конкретными правилами и настройками.

На самом деле, как будет называться такой документ – не важно. Если не нравится слово «Политика» можно переименовать в «Правила и процедуры информационной безопасности». Это не главное. Главное, что в этом документе должны быть уже четко и конкретно прописаны эти самые правила и процедуры.

Здесь остановимся немного поподробнее.

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

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

Заявка на внесение изменений в списки пользователей

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

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

Положение о разграничении прав доступа и перечень лиц

Разграничение прав доступа пользователей – мера очевидная для любого системного администратора. Дополнительно ее необходимость подкреплена мерами из приказов ФСТЭК: УПД.2 «Реализация необходимых методов (дискреционный, мандатный, ролевой или иной метод), типов (чтение, запись, выполнение или иной тип) и правил разграничения доступа», УПД.4 «Разделение полномочий (ролей) пользователей, администраторов и лиц, обеспечивающих функционирование информационной системы» и некоторых других.

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

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

Список разрешающих правил взаимодействия с внешними сетями

Правила создаются в основном во исполнение меры УПД.3 «Управление (фильтрация, маршрутизация, контроль соединений, однонаправленная передача и иные способы управления) информационными потоками между устройствами, сегментами информационной системы, а также между информационными системами».

Поскольку, как уже было сказано, шаблоны заточены под самый депрессивный вариант, здесь тоже часто таблица заполняется «белыми списками». Но можно вписывать любые другие правила, если «белые списки» не обусловлены каким-нибудь особым требованием законодательства. Форма таблицы тоже примерная, можно переделывать под своё видение как угодно.

Список разрешенного программного обеспечения

Список создается во исполнение меры ОПС.3 «Установка (инсталляция) только разрешенного к использованию программного обеспечения и (или) его компонентов». Соответственно, чтобы знать какое ПО у нас в системе разрешено, должен быть утвержден список.

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

Далее идут списки ПО и пользователей для удаленного доступа. Заполняются, если есть такой доступ и да, это тоже требования ФСТЭК.

Порядок резервирования

Здесь даже наверное требования ФСТЭК приводить не нужно. Все понимают важность бэкапов и все помнят поговорку «есть 2 типа сисадминов: те, которые делают бэкапы и те, которые будут делать бэкапы». Однако на практике при аудите информационных систем часто случается такое, что админы говорят, что бэкапы у них точно делаются, но вопросы «что именно, куда именно и как часто бэкапится» остаются без ответа.

Актуальная таблица из приложения 10 к политике ИБ поможет избежать таких ситуаций.

Что касается требований по резервированию (хотя на самом деле требования больше относятся к восстановлению), то их тоже немало. Например, часть 2 статьи 19 федерального закона «О персональных данных»:

Обеспечение безопасности персональных данных достигается, в частности:

7) восстановлением персональных данных, модифицированных или уничтоженных вследствие несанкционированного доступа к ним;

Или требование от ФСТЭК:

ОДТ.4 Периодическое резервное копирование информации на резервные машинные носители информации

План обеспечения непрерывности функционирования информационной системы

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

факапов

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

Требование ФСТЭК, которое этим планом мы частично выполняем:

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

06 Приказ о контролируемой зоне и положение о контролируемой зоне

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

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

07 План мероприятий по обеспечению безопасности…

План мероприятий можно разбить на 2 части – список разовых мероприятий по ИБ и список периодических мероприятий. Раз есть 2 части, то есть и две основные цели.

Нам часто задают такой вопрос: «А вот мы бедная государственная организация, требований по ИБ много, денег на их выполнение нет, а на носу проверка, что нам делать?». Ну, если совсем все плохо – то хотя бы составить план мероприятий. Так можно показать проверяющим, что вы в курсе о том, какие шаги вам нужно предпринять, но по какой-то причине ещё не. Это о разовых мероприятиях.

Вторая часть – периодические мероприятия, это выполнение ряда требований по постоянному внутреннему контролю информационной безопасности. Например, часть 1 статьи 18.1 закона «О персональных данных»:

1. Оператор обязан принимать меры… К таким мерам могут, в частности, относиться:

4) осуществление внутреннего контроля и (или) аудита соответствия обработки персональных данных настоящему Федеральному закону и принятым в соответствии с ним нормативным правовым актам, требованиям к защите персональных данных, политике оператора в отношении обработки персональных данных, локальным актам оператора;

08-14 Журналы…

Журналы 08-10 это журналы учета носителей информации. По ФСТЭКу есть три вида таких носителей:

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

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

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

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

Только ГИС

01 Приказ необходимости защиты информации

Нас часто спрашивают, зачем вообще нужен такой приказ. Дело в том, что 17-м приказом ФСТЭК первым мероприятием по формированию требований к защите информации установлено некое «принятие решения о необходимости защиты информации, содержащейся в информационной системе». А как мы помним, исполнение таких требований нужно подтверждать документально, вот и появился такой приказ, которым мы «принимаем решение».

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

02-03 Приказ о классификации и акт классификации

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

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

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

04 Приказ о вводе в действие

В соответствии с 17-м приказом ФСТЭК, государственная (или муниципальная) информационная система может быть введена в действие только на основании аттестата соответствия требованиям по безопасности информации.

ПДн

01 Положение о защите и обработке ПДн

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

02 Правила рассмотрения запросов

Глава 3 закона «О персональных данных» полностью посвящена правам субъекта персональных данных. Субъект ПДн имеет право писать различные запросы оператору ПДн, например, уточнить какие его данные и с какой целью обрабатываются, попросить прекратить обработку его персональных данных и т. д. Законом так же обозначены максимальные сроки, в которые оператор ПДн должен уложиться с ответом.

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

03 Приказ об утверждении перечня лиц

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

04 Политика в отношении обработки персональных данных

Не путать с политикой ИБ! Тут можно резонно спросить: «А зачем нам еще одна политика?».

Часть 2 статьи 18.1 Федерального закона «О персональных данных»:

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

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

05-06 Приказ об определении уровня защищенности персональных данных и соответствующий акт

Здесь все то же самое, что и с классификацией ГИС. Важно: если речи идет о ГИС с персональными данными, то эти два документа не нужны, так как определение уровня защищенности ПДн уже входит в акт классификации ГИС. На самом порядке определения уровня защищенности ПДн останавливаться не будем, на эту тему уже и так много написано.

07 Правила обработки ПДн без использования средств автоматизации

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

Такой обработке ПДн посвящено целое постановление Правительства РФ. Рассматриваемый внутренний документ как раз призван выполнить требования этого постановления. Тут главное — внимательно смотреть какие положения относятся к реальной ситуации, а какие – нет. Например, если нет проходной, на которой вахтер записывает проходящих на территорию в журнал, то соответствующие положения, касающиеся таких журналов нужно убрать.

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

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

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

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

4) автоматизированная обработка персональных данных — обработка персональных данных с помощью средств вычислительной техники;

Постановление Правительство не может противоречить Федеральному закону. В итоге, неавтоматизированная обработка ПДн – все, что вне информационных систем (в основном – бумажные носители).

08 Приказ о комиссии по уничтожению ПДн и форма акта уничтожения

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

09 Приказ об утверждении мест хранения ПДн

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

10 Форма согласия субъекта на обработку его ПДн

Для случаев, когда с субъектов ПДн необходимо получать согласие в письменной форме. Здесь при изменении шаблона главное помнить, что содержание письменного согласия на обработку ПДн строго регламентировано частью 4 статьи 9 Федерального закона «О персональных данных».

11 Положение о видеонаблюдении

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

12 Форма соглашения о неразглашении персональных данных

Подписывают наши сотрудники, допущенные к обработке ПДн (как к автоматизированной, так и неавтоматизированной).

13 Журнал учета обращений граждан

Работает в связке с правилами рассмотрения запросов субъектов ПДн. Все поступающие запросы регистрируем – здесь. Проверяющие требуют наличие журнала, даже если не было ни одного запроса.

СКЗИ

Здесь представлены документы, учитывающие требования ФСБ по обращению с криптосредствами. Соответственно, они не нужны, если криптография не применяется. Поскольку многие требования довольно старые и достаточно жесткие (один из руководящих документов аж от 2001 года), мы постарались как-то сбалансировать внутренние документы, чтобы и вам и нам, как говорится. Но проверяющие от ФСБ у нас ребята самые непредсказуемые, поэтому эти документы у нас часто дополняются и изменяются.

Заключение

Надеемся, что этот

небольшой

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

    ГОСТ Р ИСО/МЭК 27002-2021

 НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

 Информационные технологии

 МЕТОДЫ И СРЕДСТВА ОБЕСПЕЧЕНИЯ БЕЗОПАСНОСТИ

 Свод норм и правил применения мер обеспечения информационной безопасности

 Information technology. Security techniques. Code of practice for information security controls

ОКС 35.030

Дата введения 2021-11-30

 Предисловие

1 ПОДГОТОВЛЕН Федеральным государственным учреждением «Федеральный исследовательский центр «Информатика и управление» Российской академии наук» (ФИЦ ИУ РАН), Обществом с ограниченной ответственностью «Информационно-аналитический вычислительный центр» (ООО ИАВЦ) и Акционерным обществом «Эшелон — Северо-Запад» (АО «Эшелон-СЗ») на основе собственного перевода на русский язык англоязычной версии стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК 022 «Информационные технологии»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ

Приказом Федерального агентства по техническому регулированию и метрологии от 20 мая 2021 г. N 416-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК 27002:2013* «Информационные технологии. Методы и средства обеспечения безопасности. Свод норм и правил применения мер обеспечения информационной безопасности» (ISO/IEC 27002:2013 «Information technology — Security techniques — Code of practice for information security controls», IDT), включая технические поправки: Cor.1:2014; Cor.2:2015.     

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

ИСО/МЭК 27002 разработан подкомитетом ПК 27 «Методы и средства обеспечения безопасности ИТ» Совместного технического комитета СТК 1 «Информационные технологии» Международной организации по стандартизации (ИСО) и Международной электротехнической комиссии (МЭК).

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

приложении ДА

5 ВЗАМЕН

ГОСТ Р ИСО/МЭК 27002-2012

6 Некоторые положения международного стандарта, указанного в пункте 4, могут являться объектом патентных прав. ИСО и МЭК не несут ответственности за идентификацию подобных патентных прав

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

статье 26 Федерального закона от 29 июня 2015 г. N 162-ФЗ «О стандартизации в Российской Федерации «. Информация об изменениях к настоящему стандарту публикуется в ежегодном (по состоянию на 1 января текущего года) информационном указателе «Национальные стандарты», а официальный текст изменений и поправок — в ежемесячном информационном указателе «Национальные стандарты». В случае пересмотра (замены) или отмены настоящего стандарта соответствующее уведомление будет опубликовано в ближайшем выпуске ежемесячного информационного указателя «Национальные стандарты». Соответствующая информация, уведомление и тексты размещаются также в информационной системе общего пользования — на официальном сайте Федерального агентства по техническому регулированию и метрологии в сети Интернет (www.gost.ru)

 Введение

0.1 Общие положения

_______________

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

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

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

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

Многие информационные системы не разрабатывались безопасными в контексте ИСО/МЭК 27001 [10] и настоящего стандарта. Безопасность, которая может быть достигнута с помощью технических средств, ограничена и должна поддерживаться надлежащим управлением и процедурами. Процесс определения мер обеспечения ИБ, которые должны быть внедрены, требует тщательного планирования и внимания к деталям. Эффективная СМИБ нуждается в поддержке со стороны всех работников организации. Также может потребоваться участие акционеров, поставщиков или других внешних сторон. Кроме того, могут потребоваться консультации внешних специалистов.

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

0.2 Требования информационной безопасности

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

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

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

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

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

ИСО/МЭК 27005 [11] предоставляет руководство по менеджменту рисков ИБ, которое включает в себя рекомендации по оценке, коммуникации, мониторингу и пересмотру рисков.

0.3 Выбор мер обеспечения информационной безопасности

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

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

Некоторые из мер обеспечения ИБ, приведенных в настоящем стандарте, могут рассматриваться как руководство по менеджменту ИБ и применимы для большинства организаций. Информация о мерах обеспечения ИБ и руководстве по их применению приведена ниже. Более подробная информация о выборе мер обеспечения ИБ и других вариантах обработки риска содержится в ИСО/МЭК 27005 [11].

0.4 Разработка собственных рекомендаций

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

0.5 Вопросы жизненного цикла

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

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

0.6 Связанные стандарты

В то время как настоящий стандарт содержит руководство по применению достаточно широкого комплекса мер обеспечения ИБ, универсально применимого во множестве организаций различного типа, в других стандартах семейства ИСО/МЭК 27000 представлены дополнительные рекомендации или требования в отношении других частных аспектов менеджмента ИБ.

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

      1 Область применения

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

Настоящий стандарт предназначен для использования организациями, которые намерены:

a) выбрать меры обеспечения ИБ в процессе внедрения системы менеджмента информационной безопасности на основе ИСО/МЭК 27001 [10];

b) внедрить общепринятые меры обеспечения ИБ;

c) разработать свои собственные руководства по менеджменту ИБ.

      2 Нормативные ссылки

В настоящем стандарте использована нормативная ссылка на следующий стандарт. Для датированных ссылок применяют только указанное издание, для недатированных — последнее издание (включая все изменения).

ISO/IEC 27000, Information technology — Security techniques — Information security management systems — Overview and vocabulary (Информационные технологии. Методы и средства обеспечения безопасности. Системы менеджмента информационной безопасности. Общий обзор и терминология)

      3 Термины и определения

В настоящем стандарте применены термины по ИСО/МЭК 27000.

      4 Структура стандарта

Настоящий стандарт состоит из 14 разделов, содержащих в совокупности 114 конкретных мер обеспечения ИБ, сгруппированных в 35 основных категорий.

      4.1 Разделы

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

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

      4.2 Категории мер обеспечения информационной безопасности

Каждая основная категория содержит:

a) цель применения мер, которая содержит описание того, что должно быть достигнуто;

b) одну или несколько мер обеспечения ИБ, которые могут быть применены для достижения цели применения меры.

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

Мера обеспечения ИБ

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

Руководство по применению

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

Дополнительная информация

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

      5 Политики информационной безопасности

      5.1 Руководящие указания в части информационной безопасности

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

5.1.1 Политики информационной безопасности

Мера обеспечения ИБ

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

Руководство по применению

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

Политики ИБ должны учитывать требования, порождаемые:

a) бизнес-стратегией;

b) нормативными актами, требованиями регуляторов, договорами;

c) текущей и прогнозируемой средой угроз ИБ.

Политика ИБ должна содержать положения, касающиеся:

a) определения ИБ, целей и принципов, которыми необходимо руководствоваться в рамках деятельности, связанной с ИБ;

b) определения ролей по менеджменту ИБ и распределения общих и конкретных обязанностей;

c) процессов обработки отклонений и исключений;

d) лиц, несущих ответственность за неисполнение политик ИБ.

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

Примерами таких областей политик могут быть:

a) управление доступом (раздел 9);

b) категорирование и обработка информации (см. 8.2);

c) физическая безопасность и защита от воздействия окружающей среды (раздел 11);

d) области, ориентированные на конечного пользователя:

1) допустимое использование активов (см. 8.1.3);

2) «чистый стол» и «чистый экран» (см. 11.2.9);

3) передача информации (см. 13.2.1);

4) мобильные устройства и дистанционная работа (см. 6.2);

5) ограничения на установку и использование программного обеспечения (см. 12.6.2);

e) резервное копирование (см. 12.3);

f) передача информации (см.13.2);

g) защита от вредоносных программ (см. 12.2);

h) управление техническими уязвимостями (см. 12.6.1);

i) криптография (раздел 10);

j) безопасность коммуникаций (раздел 13);

k) конфиденциальность и защита персональных данных (см. 18.1.4);

I) взаимоотношения с поставщиками (раздел 15).

Эти политики должны быть доведены до сведения всех работников и причастных внешних сторон в актуальной, доступной и понятной для предполагаемого читателя форме, например в контексте «программы информирования, обучения и практической подготовки (тренинги) в области информационной безопасности» (см. 7.2.2).

Дополнительная информация

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

Если какие-либо политики ИБ распространяются за пределы организации, то следует следить за тем, чтобы никакая конфиденциальная информация не была разглашена.

Некоторые организации используют другие термины для документов-политик, например «Стандарты», «Инструкции», «Правила».

5.1.2 Пересмотр политик информационной безопасности

Мера обеспечения ИБ

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

Руководство по применению

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

При пересмотре политик ИБ следует учитывать результаты проверок со стороны высшего руководства.

Высшее руководство должно утвердить пересмотренную политику.

      6 Организация деятельности по информационной безопасности

      6.1 Внутренняя организация деятельности по обеспечению информационной безопасности

Цель: Создать структуру органов управления для инициирования и контроля внедрения и функционирования ИБ в организации.

6.1.1 Роли и обязанности по обеспечению информационной безопасности

Мера обеспечения ИБ

Все обязанности по обеспечению ИБ должны быть определены и распределены.

Руководство по применению

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

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

Должны быть определены области, за которые лица несут ответственность. В частности, следует проделать следующее:

a) активы и процессы ИБ должны быть идентифицированы и описаны;

b) для каждого актива или процесса ИБ следует назначить ответственное лицо, при этом следует детально задокументировать возложенную ответственность;

c) должны быть определены и задокументированы уровни полномочий;

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

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

Дополнительная информация

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

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

6.1.2 Разделение обязанностей

Мера обеспечения ИБ

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

Руководство по применению

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

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

Дополнительная информация

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

6.1.3 Взаимодействие с органами власти

Мера обеспечения ИБ

Должны поддерживаться соответствующие контакты с уполномоченными органами власти.

Руководство по применению

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

Дополнительная информация

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

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

6.1.4 Взаимодействие с профессиональными сообществами

Мера обеспечения ИБ

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

Руководство по применению

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

a) получения актуальной информации о происходящем в сфере ИБ и расширения знаний о лучших практиках;

b) обеспечения актуальности и полноты понимания среды ИБ;

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

d) получения консультаций у специалистов по ИБ;

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

f) обеспечения подходящих точек взаимодействия при обработке инцидентов ИБ (раздел 16).

Дополнительная информация

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

6.1.5 Информационная безопасность при управлении проектом

Мера обеспечения ИБ

ИБ должна рассматриваться при управлении проектом независимо от типа проекта.

Руководство по применению

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

a) цели ИБ включены в цели проекта;

b) оценку риска ИБ проводят на ранней стадии проекта для определения необходимых вариантов его обработки;

c) ИБ является частью всех этапов применяемой методологии проекта.

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

      6.2 Мобильные устройства и дистанционная работа

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

6.2.1 Политика использования мобильных устройств

Мера обеспечения ИБ

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

Руководство по применению

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

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

a) регистрацию мобильных устройств;

b) требования к физической защите;

c) ограничения на установку программного обеспечения;

d) требования к версиям программного обеспечения мобильного устройства и применению исправлений;

e) ограничение подключения к информационным сервисам;

f) управление доступом;

g) криптографические методы обеспечения ИБ;

h) защиту от вредоносного программного обеспечения;

i) возможности дистанционного отключения, стирания или блокировки;

j) резервное копирование;

k) использование веб-сервисов и веб-приложений;

I) контроль получения прав «root» на устройстве.

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

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

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

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

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

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

Дополнительная информация

Беспроводные сети для мобильных устройств похожи на другие типы сетей, однако имеют важные отличия, которые необходимо учитывать при определении мер обеспечения ИБ. Типичными отличиями являются:

a) некоторые беспроводные протоколы, обеспечивающие безопасность, недостаточно развиты и имеют известные недостатки;

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

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

6.2.2 Дистанционная работа

Мера обеспечения ИБ

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

Руководство по применению

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

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

b) предлагаемая физическая среда дистанционной работы;

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

d) предоставление доступа к виртуальному рабочему столу, который предотвращает обработку и хранение информации на личном оборудовании;

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

f) использование домашних сетей и установление требований или ограничений на конфигурацию сервисов беспроводных сетей;

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

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

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

j) требования к защите от вредоносных программ и межсетевым экранам.

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

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

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

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

d) физическую безопасность;

е) правила и рекомендации по доступу членов семьи и посетителей к оборудованию и информации;

f) предоставление технической и программной поддержки и обслуживания;

g) страхование;

h) процедуры резервного копирования и обеспечения непрерывности бизнеса;

i) аудит и мониторинг безопасности;

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

k) предоставление доступа к корпоративной информации.

Дополнительная информация

К термину «дистанционная работа» относятся все формы работы вне офиса, в том числе нетрадиционная рабочая среда, такая как «работа на дому», «гибкое рабочее место» и «виртуальное рабочее место».

      7 Безопасность, связанная с персоналом

      7.1 При приеме на работу

Цель: Обеспечить уверенность в том, что работники и подрядчики понимают свои обязанности и подходят для роли, на которую они рассматриваются.

7.1.1 Проверка

Мера обеспечения ИБ

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

Руководство по применению

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

a) наличие удовлетворительных характеристик, например одной от организации и одной от физического лица;

b) проверку (на полноту и точность) биографии заявителя;

c) подтверждение заявленного образования и профессиональной квалификации;

d) независимую проверку личности (паспорт или иной подобный документ);

e) более детальную проверку, такую как обзор кредитной истории или проверку судимостей.

Когда работника принимают на работу для выполнения определенной роли ИБ, необходимо удостовериться, что кандидат:

a) обладает необходимыми компетенциями для этой роли;

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

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

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

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

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

7.1.2 Правила и условия работы

Мера обеспечения ИБ

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

Руководство по применению

Договорные обязательства для работников и подрядчиков должны отражать политики организации в области ИБ, дополнительно уточняя и утверждая:

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

b) юридическую ответственность и права работника или подрядчика, например в отношении законов об авторском праве или защите данных (см. 18.1.2 и 18.1.4);

c) обязанности по категорированию информации и управлению информацией организации, иными активами, связанными с информацией, средствами ее обработки и информационными системами, используемыми работником или подрядчиком (раздел 8). (Внесена техническая поправка Cor.1:2014);

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

e) действия, которые необходимо предпринять, если работник или подрядчик не соблюдает требования безопасности организации (см. 7.2.3).

Роли и обязанности в области ИБ должны быть доведены до сведения кандидатов до их приема на работу.

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

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

Дополнительная информация

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

      7.2 Во время работы

Цель: Обеспечить уверенность в том, что работники и подрядчики осведомлены о своих обязанностях в отношении ИБ и выполняют их.

7.2.1 Обязанности руководства организации

Мера обеспечения ИБ

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

Руководство по применению

В обязанности руководства входит обеспечение того, чтобы работники и подрядчики:

a) были надлежащим образом проинформированы об их ролях и обязанностях в области ИБ до предоставления доступа к конфиденциальной информации или информационным системам;

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

c) были мотивированы выполнять политики ИБ организации;

d) были осведомлены об ИБ настолько, насколько это предполагают их роли и обязанности в организации (см. 7.2.2);

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

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

g) имели канал для анонимного сообщения о нарушениях политик или процедур ИБ («информирование о нарушениях»).

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

Дополнительная информация

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

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

7.2.2 Осведомленность, обучение и практическая подготовка (тренинги) в области информационной безопасности

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

Обучение и практическая подготовка в области ИБ должна также охватывать общие аспекты, такие как:

a) заявление руководства о приверженности ИБ во всей организации;

b) необходимость ознакомления с правилами и обязательствами, применяемыми в области ИБ, определенными в политиках, стандартах, законах, положениях, договорах и соглашениях;

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

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

e) контакты и ресурсы для получения дополнительной информации и консультаций по вопросам ИБ, включая дополнительные материалы по обучению и подготовке в области ИБ.

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

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

Дополнительная информация

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

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

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

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

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

7.2.3 Дисциплинарный процесс

Мера обеспечения ИБ

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

Руководство по применению

Дисциплинарный процесс не должен быть инициирован, пока не будет уверенности в том, что нарушение ИБ действительно имело место (см. 16.1.7).

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

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

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

Дополнительная информация

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

      7.3 Увольнение и смена места работы

Цель: Защита интересов организации при смене места работы или увольнении работника.

7.3.1 Прекращение или изменение трудовых обязанностей

Мера обеспечения ИБ

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

Руководство по применению

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

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

Дополнительная информация

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

Работников и подрядчиков необходимо информировать об изменениях в штате и порядке работы.

      8 Менеджмент активов

      8.1 Ответственность за активы

Цель: Идентификация активов организации и определение соответствующих обязанностей по их защите.

8.1.1 Инвентаризация активов

Мера обеспечения ИБ

Информация, средства обработки информации и другие активы, связанные с информацией, должны быть идентифицированы, а также должен быть составлен и поддерживаться в актуальном состоянии перечень этих активов. (Внесена техническая поправка Сог.1:2014).

Руководство по применению

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

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

Для каждого актива, включенного в перечень, должен быть определен его владелец (см. 8.1.2) и проведено категорирование (см. 8.2).

Дополнительная информация

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

ИСО/МЭК 27005 [11] предоставляет примеры активов, которые могут быть приняты во внимание организацией в процессе идентификации активов. Процесс составления перечня активов является важной предпосылкой управления рисками (см. также ИСО/МЭК 27001 [10] и ИСО/МЭК 27005 [11]).

8.1.2 Владение активами

Мера обеспечения ИБ

Для каждого актива, включенного в перечень инвентаризации, должен быть определен его владелец.

Руководство по применению

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

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

Владелец актива должен:

a) обеспечить проведение инвентаризации активов;

b) обеспечить, чтобы активы были должным образом категорированы и защищены;

c) определять и периодически пересматривать ограничения доступа и категорирование важных активов с учетом действующих политик управления доступом;

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

Дополнительная информация

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

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

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

8.1.3 Допустимое использование активов

Мера обеспечения ИБ

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

Руководство по применению

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

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

8.1.4 Возврат активов

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

      8.2 Категорирование информации

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

8.2.1 Категорирование информации

Мера обеспечения ИБ

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

Руководство по применению

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

Владельцы информационных активов должны быть ответственными за их категорирование.

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

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

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

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

Дополнительная информация

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

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

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

a) раскрытие информации не приведет к ущербу;

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

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

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

8.2.2 Маркировка информации

Мера обеспечения ИБ

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

Руководство по применению

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

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

Дополнительная информация

Маркировка конфиденциальной информации является ключевым требованием для мероприятий по обмену информацией. Физические метки и метаданные являются наиболее распространенными формами меток.

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

8.2.3 Обращение с активами

Мера обеспечения ИБ

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

Руководство по применению

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

Должны быть рассмотрены следующие вопросы:

a) ограничение доступа, обеспечивающее выполнение требований по защите для каждой категории;

b) ведение официального учета уполномоченных обладателей активов;

c) защита временных или постоянных копий информации на уровне, соответствующем уровню защиты оригиналов информации;

d) хранение ИТ-активов в соответствии с инструкциями производителей;

e) четкая маркировка всех копий носителей для информирования уполномоченного обладателя.

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

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

      8.3 Обращение с носителями информации

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

8.3.1 Управление съемными носителями информации

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

c) все носители следует хранить в безопасном, надежном месте в соответствии с инструкциями производителей;

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

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

f) несколько копий ценных данных следует хранить на отдельных носителях для снижения риска случайного повреждения или потери данных;

g) для уменьшения возможности потери данных должна быть предусмотрена регистрация съемных носителей информации;

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

i) в случае необходимости использования съемных носителей перенос информации на них необходимо контролировать.

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

8.3.2 Утилизация носителей информации

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

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

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

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

Дополнительная информация

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

8.3.3 Перемещение физических носителей

Мера обеспечения ИБ

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

Руководство по применению

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

a) должен использоваться надежный транспорт или курьеры;

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

c) должны быть разработаны процедуры для идентификации курьеров;

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

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

Дополнительная информация

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

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

      9 Управление доступом

      9.1 Требование бизнеса по управлению доступом

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

9.1.1 Политика управления доступом

Мера обеспечения ИБ

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

Руководство по применению

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

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

Политика должна учитывать следующее:

a) требования безопасности бизнес-приложений;

b) политики распространения информации и авторизации, например принцип «необходимого знания», уровни ИБ и категорирование информации (см. 8.2);

c) соответствие между правами доступа и политиками категорирования информации для систем и сетей;

d) соответствующие законодательные и любые договорные обязательства, касающиеся ограничения доступа к данным или сервисам (см. 18.1);

e) управление правами доступа в распределенных средах и сетях, которые допускают все типы соединений;

f) разделение ролей по управлению доступом, например запрос доступа, авторизация доступа, администрирование доступа;

g) требования к формальной авторизации запросов доступа (см. 9.2.1 и 9.2.2);

h) требования к периодическому пересмотру прав доступа (см. 9.2.6);

i) аннулирование прав доступа (см. 9.2.6);

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

k) роли с привилегированным доступом (см. 9.2.3).

Дополнительная информация

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

a) установление правил, основанных на утверждении «Все в общем случае запрещено, пока явно не разрешено», а не на более слабом принципе «Все в общем случае разрешено, пока явно не запрещено»;

b) изменения маркировки информации (см. 8.2.2), которые инициируются автоматически средствами обработки информации и которые инициируются пользователями;

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

d) правила, которые требуют определенной процедуры утверждения до вступления в силу, и те, которые этого не требуют.

Правила управления доступом должны быть зафиксированы в формальных процедурах (см. 9.2, 9.3, 9.4), и под них определены обязанности (см. 6.1, 9.3).

Управление доступом на основе ролей — это подход, успешно используемый многими организациями для связи прав доступа с бизнес-ролями.

Есть два часто применяемых принципа, определяющих политику управления доступом:

e) принцип «необходимого знания»: вам предоставляется доступ только к той информации, которая вам необходима для выполнения ваших задач (различные задачи/роли подразумевают различные «необходимые знания» и следовательно различные профили доступа);

f) принцип «необходимого использования»: вам предоставляется доступ только к тем средствам обработки информации (ИТ-оборудование, приложения, процедуры, помещения), которые необходимы для выполнения задачи/работы/роли.

9.1.2 Доступ к сетям и сетевым сервисам

Мера обеспечения ИБ

Пользователям следует предоставлять доступ только к тем сетям и сетевым сервисам, на использование которых они получили конкретное разрешение.

Руководство по применению

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

a) сети и сетевые сервисы, к которым разрешен доступ;

b) процедуры авторизации для определения того, кому к каким сетям и сетевым сервисам разрешен доступ;

c) меры управления и процедуры для защиты доступа к сетевым соединениям и сетевым сервисам;

d) средства, используемые для доступа к сетям и сетевым сервисам (например, использование VPN или беспроводной сети);

e) требования к аутентификации пользователя для доступа к различным сетевым сервисам;

f) мониторинг использования сетевых сервисов.

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

Дополнительная информация

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

      9.2 Процесс управления доступом пользователей

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

9.2.1 Регистрация и отмена регистрации пользователей

Мера обеспечения ИБ

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

Руководство по применению

Процесс управления идентификаторами пользователей должен включать в себя:

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

b) немедленное отключение или удаление идентификаторов пользователей, покинувших организацию (см. 9.2.6);

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

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

Дополнительная информация

Предоставление или аннулирование прав доступа к информации или средствам обработки информации обычно представляет собой двухэтапную процедуру:

a) назначение и активация или аннулирование идентификатора пользователя;

b) предоставление или аннулирование прав доступа для этого идентификатора пользователя (см. 9.2.2).

9.2.2 Предоставление пользователю права доступа

Мера обеспечения ИБ

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

Руководство по применению

Процесс предоставления доступа для назначения или аннулирования прав доступа для идентификаторов пользователей должен включать в себя:

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

b) проверку того, что предоставляемый уровень доступа соответствует политикам доступа (см. 9.1) и согласуется с другими требованиями, такими как разделение обязанностей (см. 6.1.2);

c) обеспечение того, что права доступа не будут активированы (например, поставщиками услуг) до завершения процедур аутентификации;

d) ведение централизованной регистрации прав доступа, связываемых с идентификатором пользователя, к информационным системам и сервисам;

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

f) периодический пересмотр права доступа совместно с владельцами информационных систем или сервисов (см. 9.2.5).

Дополнительная информация

Следует рассмотреть вопрос о создании ролей пользователей, которые вытекают из требований бизнеса и определяют права доступа для пользователей, объединяя ряд прав доступа в типовые профили доступа пользователей. Запросы на доступ и пересмотр прав доступа (см. 9.2.4) легче обрабатывать на уровне таких ролей, чем на уровне отдельных прав.

Следует рассмотреть вопрос включения в контракты с работниками и подрядчиками положений, предусматривающих санкции в случае совершения работником или подрядчиком попыток несанкционированного доступа (см. 7.1.2, 7.2.3, 13.2.4; 15.1.2).

9.2.3 Управление привилегированными правами доступа

Мера обеспечения ИБ

Распределение и использование привилегированных прав доступа следует ограничивать и контролировать.

Руководство по применению

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

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

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

c) все процессы аутентификации и назначения привилегий должны регистрироваться. Привилегированные права доступа не должны предоставляться до завершения процесса аутентификации;

d) должны быть определены требования для установления срока действия привилегированных прав доступа;

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

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

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

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

Дополнительная информация

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

9.2.4 Процесс управления секретной аутентификационной информацией пользователей

Мера обеспечения ИБ

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

Руководство по применению

Этот процесс должен включать в себя следующие требования:

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

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

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

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

e) временная секретная аутентификационная информация должна быть уникальной для конкретного пользователя и не должна быть легко угадываемой;

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

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

Дополнительная информация

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

9.2.5 Пересмотр прав доступа пользователей

Мера обеспечения ИБ

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

Руководство по применению

При пересмотре прав доступа следует учитывать следующее:

a) права доступа пользователей следует пересматривать как через определенные интервалы времени, так и после любых изменений, таких как повышение или понижение в должности, или увольнение (раздел 7);

b) права доступа пользователя следует пересматривать и переназначать в случае изменения его роли в организации;

c) полномочия для привилегированных прав доступа следует пересматривать чаще;

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

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

Дополнительная информация

Эта мера компенсирует возможные недостатки в выполнении мер обеспечения ИБ, приведенных в 9.2.1, 9.2.2, 9.2.6.

9.2.6 Аннулирование или корректировка прав доступа

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

b) текущие обязанности работника, внешнего пользователя или любого другого пользователя;

c) ценность активов, находящихся в текущем доступе.

Дополнительная информация

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

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

      9.3 Ответственность пользователей

Цель: Установить ответственность пользователей за защиту их аутентификационной информации.

9.3.1 Использование секретной аутентификационной информации

Мера обеспечения ИБ

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

Руководство по применению

Всем пользователям должно быть рекомендовано:

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

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

c) изменять секретную аутентификационную информацию всякий раз, когда есть какие-либо признаки ее возможной компрометации;

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

1) легко запомнить;

2) не основаны на том, о чем кто-либо другой может легко догадаться или вычислить на основе личной информации, например имена, номера телефонов и даты рождения и т.д.;

3) неуязвимы к атакам по словарю (т.е. не состоят из слов, включенных в словари);

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

5) если являются временными, изменяются при первом входе в систему;

6) не делятся секретной аутентификационной информацией;

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

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

Дополнительная информация

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

      9.4 Управление доступом к системам и приложениям

Цель: Предотвратить несанкционированный доступ к системам и приложениям.

9.4.1 Ограничение доступа к информации

Мера обеспечения ИБ

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

Руководство по применению

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

Для обеспечения выполнения требований по ограничению доступа следует учитывать следующее:

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

b) управление тем, какие данные могут быть доступны конкретному пользователю;

c) управление правами доступа пользователей, например чтение, запись, удаление и выполнение;

d) управление правами доступа других приложений;

e) ограничение информации, содержащейся в выходных данных;

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

9.4.2 Безопасные процедуры входа в систему

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

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

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

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

e) защищать от попыток входа в систему методом полного перебора (грубой силы);

f) регистрировать неуспешные и успешные попытки входа;

g) фиксировать событие безопасности при обнаружении попыток или фактов успешного нарушения процедуры входа;

h) отображать следующую информацию по завершении успешного входа в систему:

— дата и время предыдущего успешного входа;

— сведения всех неудачных попыток входа с момента последнего успешного входа;

i) не отображать вводимый пароль;

j) не передавать пароли в открытом виде по сети;

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

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

Дополнительная информация

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

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

9.4.3 Система управления паролями

Мера обеспечения ИБ

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

Руководство по применению

Система управления паролями должна:

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

b) позволять пользователям выбирать и изменять свои собственные пароли и включать процедуру подтверждения для обеспечения возможности исправления ошибок ввода;

c) обеспечивать выбор качественных паролей;

d) заставлять пользователей изменять свои пароли при первом входе в систему;

e) агитировать регулярно или по мере необходимости менять пароли;

f) вести учет ранее использованных паролей и предотвращать их повторное использование;

g) не отображать пароли на экране при их вводе;

h) хранить файлы с паролями отдельно от данных прикладных систем;

i) хранить и передавать пароли в защищенном виде.

Дополнительная информация

Некоторые приложения требуют, чтобы пароли пользователей назначались независимой стороной; в таких случаях пункты b), d) и е) вышеуказанного руководства к системе не применяются. В большинстве случаев пароли выбирают и меняют пользователи.

9.4.4 Использование привилегированных служебных программ

Мера обеспечения ИБ

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

Руководство по применению

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

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

b) отделять служебные программы от прикладного программного обеспечения;

c) ограничивать использование служебных программ минимально возможным числом доверенных, авторизованных пользователей (см. 9.2.3);

d) предъявлять требования по авторизации на использование специальных служебных программ;

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

f) регистрировать все случаи использования служебных программ;

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

h) удалять или отключать все ненужные служебные программы;

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

Дополнительная информация

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

9.4.5 Управление доступом к исходному коду программы

Мера обеспечения ИБ

Доступ к исходному коду программ должен быть ограничен.

Руководство по применению

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

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

b) исходный код программы и библиотеки исходных кодов программы должны управляться в соответствии с установленными процедурами;

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

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

e) листинги программ должны храниться в безопасной среде;

f) должны сохраняться записи всех обращений к библиотекам исходных кодов;

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

Если исходный код программы предполагается публиковать, следует принять во внимание дополнительные меры обеспечения ИБ для получения гарантии его целостности (например, электронная подпись).

_______________

      10.1 Средства криптографической защиты информации

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

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

Мера обеспечения ИБ

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

Руководство по применению

При разработке политики следует учитывать следующее:

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

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

c) использование шифрования для защиты информации, передаваемой с помощью мобильных или съемных носителей, или по линиям связи;

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

e) роли и обязанности, например, кто несет ответственность за:

1) внедрение политики;

2) управление ключами, включая их генерацию (см. 10.1.2);

f) стандарты, которые должны быть приняты для эффективной реализации во всей организации (какое решение используется и для каких бизнес-процессов);

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

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

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

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

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

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

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

Дополнительная информация

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

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

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

10.1.2 Управление ключами

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

Система управления ключами должна базироваться на согласованном наборе стандартов, процедур и методов обеспечения безопасности для:

a) генерации ключей для различных криптографических систем и приложений;

b) выдачи и получения сертификатов открытого ключа;

c) распределения ключей тем, кому они предназначены, в том числе порядок активации ключей при получении;

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

e) смены или обновления ключей, включая руководство о том, когда следует менять ключи и как это сделать;

f) действий со скомпрометированными ключами;

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

h) восстановления поврежденных и утерянных ключей;

i) резервного копирования или архивирования ключей;

j) уничтожения ключей;

k) регистрации и аудита действий по управлению ключами.

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

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

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

Дополнительная информация

Управление криптографическими ключами имеет важное значение для эффективного использования криптографических методов. ИСО/МЭК 11770 [2], [3], [4] предоставляет дополнительную информацию об управлении ключами.

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

      11 Физическая безопасность и защита от воздействия окружающей среды

      11.1 Зоны безопасности

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

11.1.1 Физический периметр безопасности

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

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

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

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

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

Дополнительная информация

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

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

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

11.1.2 Меры и средства контроля и управления физическим доступом

Мера обеспечения ИБ

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

Руководство по применению

Следует принять во внимание следующие рекомендации:

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

b) доступ в зоны обработки или хранения конфиденциальной информации следует контролировать и предоставлять только авторизованным лицам путем применения соответствующих мер, например реализацией механизма двухфакторной аутентификации, такой, как карты доступа или секретным ПИН-кодом;

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

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

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

f) права доступа к зонам безопасности следует регулярно пересматривать и обновлять, а при необходимости отменять (см. 9.25*, 9.2.6).

11.1.3 Безопасность зданий, помещений и оборудования

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

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

11.1.4 Защита от внешних угроз и угроз со стороны окружающей среды

Мера обеспечения ИБ

Должны быть разработаны и реализованы меры физической защиты от стихийных бедствий, злоумышленных атак или аварий.

Руководство по применению

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

11.1.5 Работа в зонах безопасности

Мера обеспечения ИБ

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

Руководство по применению

Следует принять во внимание следующие рекомендации:

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

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

c) незанятые зоны безопасности должны быть физически заперты и периодически проверяться;

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

Меры по работе в зонах безопасности включают в себя меры обеспечения ИБ для работников и представителей внешней стороны, работающих в зоне безопасности, и охватывают все виды деятельности, выполняемые в зоне безопасности.

11.1.6 Зоны погрузки и разгрузки

Мера обеспечения ИБ

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

Руководство по применению

Следует принять во внимание:

а) доступ к зоне погрузки и разгрузки снаружи здания разрешен только идентифицированному и авторизованному персоналу;

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

c) внешние двери зоны погрузки и разгрузки должны быть закрыты в то время, когда внутренние открыты;

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

e) при поступлении материальные ценности должны быть зарегистрированы в соответствии с процедурами управления активами (раздел 8);

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

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

      11.2 Оборудование

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

11.2.1 Размещение и защита оборудования

Мера обеспечения ИБ

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

Руководство по применению

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

a) оборудование следует размещать таким образом, чтобы свести к минимуму излишний доступ в рабочие зоны;

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

c) оборудование для хранения информации следует защищать от несанкционированного доступа;

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

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

f) должны быть установлены правила по приему пищи, питью и курению вблизи средств обработки информации;

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

h) внешняя молниезащита должна быть установлена на всех зданиях, а фильтры молниезащиты должны ставиться на всех входящих силовых и коммуникационных линиях;

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

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

11.2.2 Вспомогательные услуги

Мера обеспечения ИБ

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

Руководство по применению

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

a) соответствовать спецификациям производителя оборудования и местным законодательным требованиям;

b) регулярно оцениваться на предмет способности соответствовать развитию бизнеса и взаимодействию с другими вспомогательными услугами;

c) регулярно осматриваться и проверяться для обеспечения гарантии их надлежащего функционирования;

d) при необходимости быть оборудованы сигнализацией для выявления неисправностей;

e) при необходимости иметь несколько каналов, физически отделенных друг от друга.

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

Дополнительная информация

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

11.2.3 Безопасность кабельной сети

Мера обеспечения ИБ

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

Руководство по применению

Для обеспечения безопасности кабельной сети следует рассмотреть следующие рекомендации:

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

b) силовые кабели должны быть проложены отдельно от телекоммуникационных для предотвращения помех;

c) для информации ограниченного доступа следует рассмотреть дополнительные меры обеспечения ИБ, а именно:

1) использование защищенных кабель-каналов, а также закрываемых помещений или шкафов в точках входа/выхода и коммутации кабелей;

2) использование электромагнитной защиты кабелей;

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

4) контроль доступа к коммутационным панелям и кабельным помещениям.

11.2.4 Техническое обслуживание оборудования

Мера обеспечения ИБ

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

Руководство по применению

Необходимо рассмотреть следующие рекомендации в отношении обслуживания оборудования:

a) оборудование следует обслуживать в соответствии с рекомендованной поставщиком периодичностью и спецификациями;

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

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

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

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

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

11.2.5 Перемещение активов

Мера обеспечения ИБ

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

Руководство по применению

Следует рассмотреть следующие рекомендации:

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

b) должны быть установлены сроки возврата активов, а после возвращения проверено их соблюдение;

c) когда это необходимо и целесообразно, следует регистрировать вынос и возврат активов;

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

Дополнительная информация

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

11.2.6 Безопасность оборудования и активов вне помещений организации

Мера обеспечения ИБ

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

Руководство по применению

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

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

a) оборудование и носители, вынесенные за пределы помещений организации, не следует оставлять без присмотра в общественных местах;

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

c) меры обеспечения информационной безопасности для работы за пределами организации, например для работы дома, удаленной работы и работы на временных точках, должны определяться на основе оценки риска и применяться в зависимости от ситуации, например запираемые шкафы для документов, политика чистого стола, управление доступом к компьютерам и защищенная связь с офисом (см. также ИСО/МЭК 27033 [15], [16], [17], [18], [19]);

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

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

Дополнительная информация

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

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

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

11.2.7 Безопасная утилизация или повторное использование оборудования

Мера обеспечения ИБ

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

Руководство по применению

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

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

Дополнительная информация

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

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

a) шифрование достаточно стойкое и охватывает весь диск (включая свободное место, файлы подкачки и т.д.);

b) ключи шифрования достаточно длинные, чтобы противостоять атакам методом полного перебора (грубой силы);

c) сами ключи шифрования хранятся в секрете (например, никогда не хранятся на том же диске).

Для получения дополнительной информации о шифровании см. раздел 10.

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

11.2.8 Оборудование, оставленное пользователем без присмотра

Мера обеспечения ИБ

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

Руководство по применению

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

a) прерывать активные сессии после завершения работы, если только они не могут быть защищены соответствующим механизмом блокировки, например защищенной паролем заставкой;

b) выходить из приложений или сетевых сервисов, когда в них больше нет необходимости;

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

11.2.9 Политика «чистого стола» и «чистого экрана»

Мера обеспечения ИБ

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

Руководство по применению

Политика «чистого стола» и «чистого экрана» должна учитывать категорирование информации (см. 8.2), законодательные и договорные требования (см. 18.1), а также соответствующие риски и корпоративную культуру организации. Следует учесть следующие рекомендации:

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

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

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

d) носители, содержащие информацию ограниченного доступа, следует забирать из принтеров немедленно.

Дополнительная информация

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

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

      12 Безопасность при эксплуатации

      12.1 Эксплуатационные процедуры и обязанности

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

12.1.1 Документально оформленные эксплуатационные процедуры

Мера обеспечения ИБ

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

Руководство по применению

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

Эксплуатационные процедуры должны содержать инструкции, в том числе:

a) по установке и настройке систем;

b) по обработке информации как в автоматизированном, так и в ручном режиме;

c) по резервному копированию (см. 12.3);

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

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

f) контакты поддержки (включая внешнюю) и эскалации на случай непредвиденных эксплуатационных или технических трудностей;

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

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

i) управления информацией системных журналов и журналов аудита (см. 12.4);

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

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

12.1.2 Процесс управления изменениями

Мера обеспечения ИБ

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

Руководство по применению

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

a) идентификацию и регистрацию существенных изменений;

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

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

d) процедуры утверждения предлагаемых изменений;

e) подтверждение того, что выполняются требования по ИБ;

f) информирование об изменении всех заинтересованных лиц;

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

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

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

Дополнительная информация

Неадекватный контроль над изменениями в средствах и системах обработки информации является распространенной причиной системных сбоев или нарушений безопасности (см. 14.2.2).

12.1.3 Управление производительностью

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

a) удаление устаревших данных (дисковое пространство);

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

c) оптимизацию пакетных заданий и расписаний;

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

e) запрет или ограничение полосы пропускания для ресурсоемких сервисов, если они не являются критически важными для бизнеса (например, потоковое видео).

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

Дополнительная информация

Данная мера обеспечения ИБ также применима к человеческим ресурсам, а также к помещениям и оборудованию.

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

Мера обеспечения ИБ

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

Руководство по применению

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

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

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

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

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

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

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

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

g) конфиденциальные данные не должны копироваться в среду системы тестирования, если для системы тестирования не предусмотрены эквивалентные меры обеспечения ИБ (см. 14.3).

Дополнительная информация

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

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

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

      12.2 Защита от вредоносных программ

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

12.2.1 Меры обеспечения информационной безопасности в отношении вредоносных программ

Мера обеспечения ИБ

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

Руководство по применению

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

a) установление формальной политики, запрещающей использование неавторизованного программного обеспечения (см. 12.6.2 и 14.2);

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

c) внедрение мер обеспечения ИБ, которые предотвращают или обнаруживают обращение к известным или предполагаемым вредоносным веб-сайтам (например, ведение черного списка);

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

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

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

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

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

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

3) проверку веб-страницы на наличие вредоносных программ;

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

i) подготовка соответствующих планов обеспечения непрерывности бизнеса для восстановления после атак с применением вредоносных программ, включая все необходимые меры по резервному копированию и восстановлению данных и программного обеспечения (см. 12.3);

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

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

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

Дополнительная информация

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

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

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

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

      12.3 Резервное копирование

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

12.3.1 Резервное копирование информации

Мера обеспечения ИБ

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

Руководство по применению

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

Политика резервного копирования должна определять требования к хранению и защите.

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

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

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

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

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

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

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

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

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

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

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

      12.4 Регистрация и мониторинг

Цель: Регистрация событий безопасности и формирование свидетельств.

12.4.1 Регистрация событий

Мера обеспечения ИБ

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

Руководство по применению

Журналы событий, где это применимо, должны включать в себя:

a) пользовательские идентификаторы;

b) действия в системе;

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

d) идентификатор устройства или местоположения, если возможно, и системный идентификатор;

e) записи об успешных и отклоненных попытках доступа к системе;

f) записи об успешных или отклоненных попытках доступа к данным и иным ресурсам;

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

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

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

j) файлы, к которым был запрошен доступ, а также вид доступа;

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

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

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

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

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

Дополнительная информация

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

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

12.4.2 Защита информации регистрационных журналов

Мера обеспечения ИБ

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

Руководство по применению

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

a) изменение типов сообщений, которые были записаны;

b) удаление или изменение журнала;

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

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

Дополнительная информация

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

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

12.4.3 Регистрационные журналы действий администратора и оператора

Мера обеспечения ИБ

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

Руководство по применению

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

Дополнительная информация

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

12.4.4 Синхронизация часов

Мера обеспечения ИБ

Часы всех систем обработки информации в рамках организации или домена безопасности должны быть синхронизированы с единым эталонным источником времени.

Руководство по применению

Внешние и внутренние требования к представлению времени, синхронизации и точности должны быть задокументированы. Такие требования могут быть правовыми, нормативными, договорными, являться требованиями стандартов или требованиями, касающимися внутреннего мониторинга. В организации должен быть определен стандартный эталон времени.

Подходы организации к получению эталонного времени из внешних источников и надежной синхронизации внутренних часов должны быть задокументированы и реализованы.

Дополнительная информация

Правильная настройка компьютерных часов важна для обеспечения точности журналов аудита, которые могут потребоваться для проведения расследований или в качестве доказательств в юридических или дисциплинарных спорах. Неточные журналы аудита могут препятствовать проведению таких расследований и подрывать достоверность таких доказательств. В качестве эталонного времени в системах регистрации могут быть использованы сигналы точного времени, передаваемые по радио и синхронизированные с национальными центрами стандартов времени и частоты. Для синхронизации всех серверов с эталоном может использоваться протокол сетевого времени (NTP).

      12.5 Контроль программного обеспечения, находящегося в эксплуатации

Цель: Обеспечить уверенность в целостности систем, находящихся в эксплуатации.

12.5.1 Установка программного обеспечения в эксплуатируемых системах

Мера обеспечения ИБ

Должны быть реализованы процедуры контроля установки программного обеспечения в системах, находящихся в эксплуатации.

Руководство по применению

Необходимо принять во внимание следующие рекомендации по управлению изменениями программного обеспечения в эксплуатируемых системах:

a) обновление эксплуатируемого программного обеспечения, приложений и программных библиотек должны выполнять только обученные администраторы при наличии соответствующего разрешения руководства (см. 9.4.5);

b) эксплуатируемые системы должны содержать только утвержденный исполняемый код и не должны содержать разрабатываемые коды или компиляторы;

c) программное обеспечение и приложения следует внедрять в эксплуатируемую систему только после обширного и успешного тестирования; тесты должны охватывать удобство использования, безопасность, влияние на другие системы, дружелюбность интерфейса и должны проводиться на выделенных для этого системах (см. 12.1.4); следует убедиться, что все соответствующие исходные программные библиотеки были обновлены;

d) должна использоваться система управления конфигурацией для контроля над всем внедренным программным обеспечением и системной документацией;

e) перед внедрением изменений должна быть разработана стратегия возврата в исходное состояние;

f) следует вести журнал всех обновлений действующих программных библиотек;

g) предыдущие версии прикладного программного обеспечения следует сохранять в качестве меры на случай непредвиденных обстоятельств;

h) старые версии программного обеспечения должны быть заархивированы вместе со всей необходимой информацией и параметрами, процедурами, деталями настройки и вспомогательным программным обеспечением на тот же срок, что и данные.

Поставляемое программное обеспечение, используемое в эксплуатируемых системах, должно поддерживаться на уровне, обеспечиваемом поставщиком. Со временем поставщики программного обеспечения перестанут поддерживать более старые версии программного обеспечения. Организация должна учитывать риски, связанные с использованием неподдерживаемого программного обеспечения.

Любое решение об обновлении до новой версии должно учитывать требования бизнеса по изменению и безопасности новой версии, например введение нового функционала, связанного с ИБ, или количество и серьезность проблем безопасности, связанных с этой версией. Пакеты исправлений программного обеспечения должны применяться тогда, когда они могут помочь устранить или снизить уязвимости ИБ (см. 12.6).

Физический или логический доступ должен предоставляться поставщикам только когда это необходимо для целей поддержки и с одобрения руководства. Действия поставщика следует контролировать (см. 15.2.1).

Компьютерное программное обеспечение может зависеть от поставляемого внешнего программного обеспечения и модулей, которые должны быть контролируемы и управляемы во избежание несанкционированных изменений, которые могут привести к уязвимостям в безопасности.

      12.6 Менеджмент технических уязвимостей

Цель: Предотвратить использование технических уязвимостей.

12.6.1 Процесс управления техническими уязвимостями

Мера обеспечения ИБ

Должна быть своевременно получена информация о технических уязвимостях используемых информационных систем, оценена подверженность организации таким уязвимостям и приняты соответствующие меры в отношении связанного с этим риска ИБ.

Руководство по применению

Актуальный и полный перечень активов (раздел является необходимым условием для эффективного управления техническими уязвимостями. Специальная информация, необходимая для поддержки управления техническими уязвимостями, включает в себя информацию о поставщике программного обеспечения, номерах версий, текущем состоянии развертывания (например, какое программное обеспечение установлено в каких системах) и работниках, ответственных за программное обеспечение в организации.

В ответ на выявление потенциальных технических уязвимостей должны быть предприняты надлежащие и своевременные действия. Необходимо придерживаться следующих указаний для создания эффективного процесса управления техническими уязвимостями:

a) организация должна определить и установить роли и обязанности, связанные с управлением техническими уязвимостями, включая их мониторинг, оценку риска, исправление ошибок, отслеживание активов и любые необходимые обязанности по координации процесса;

b) для программного обеспечения и других технологий (на основе перечня активов, см. 8.1.1) следует идентифицировать информационные ресурсы, которые будут использоваться для выявления соответствующих технических уязвимостей и поддержания осведомленности о них; эти информационные ресурсы должны обновляться в соответствии с изменениями в перечне активов или при обнаружении новых и полезных ресурсов;

c) следует определить сроки реагирования на уведомления о потенциально значимых технических уязвимостях;

d) после выявления потенциальной технической уязвимости организация должна определить связанные с ней риски и действия, которые необходимо предпринять; такие действия могут включать применение пакетов исправлений к уязвимым системам или применение компенсирующих мер обеспечения ИБ;

e) в зависимости от того, насколько срочно необходимо устранить техническую уязвимость, предпринимаемые действия должны проводиться в соответствии с мерами по управлению изменениями (см. 12.1.2) или в соответствии с процедурами реагирования на инциденты ИБ (см. 16.1.5);

f) если доступно официальное исправление, следует оценить риски, связанные с его установкой (риски, связанные с уязвимостью, следует сравнить с рисками, которые могут возникнуть вследствие установки исправления);

g) пакеты исправлений должны быть проверены и оценены до их установки, чтобы быть уверенным в том, что они не приведут к недопустимым побочным эффектам; если исправлений не выпущено, следует рассмотреть иные меры обеспечения информационной безопасности, такие как:

1) отключение сервисов и возможностей, связанных с уязвимостью;

2) настройка или добавление мер контроля доступа, например межсетевые экраны на границах сети (см. 13.1);

3) усиление мониторинга для выявления реальных атак;

4) повышение осведомленности об уязвимостях;

h) следует вести журнал всех предпринятых действий;

i) процесс управления техническими уязвимостями следует регулярно контролировать и оценивать для обеспечения его эффективности и результативности;

j) в первую очередь следует обращать внимание на системы с высоким уровнем риска;

k) эффективный процесс управления техническими уязвимостями должен быть согласован с действиями по управлению инцидентами, что позволит передавать данные об уязвимостях группе реагирования на инциденты и дополнит процесс техническими процедурами, которые должны быть выполнены в случае инцидента;

I) необходимо определить процедуру для решения ситуации, когда уязвимость была выявлена, но подходящих мер еще не существует. В этой ситуации организация должна оценить риски, связанные с известной уязвимостью, и определить соответствующие действия по обнаружению и корректировке.

Дополнительная информация

Управление техническими уязвимостями может рассматриваться как подфункция процесса управления изменениями и, как следствие, может использовать преимущества процессов и процедур управления изменениями (см. 12.1.2 и 14.2.2).

Производители часто испытывают на себе значительное давление, заключающееся в требовании выпускать пакеты исправлений как можно скорее. Следовательно существует вероятность того, что исправление не решает проблему должным образом и имеет отрицательные побочные эффекты. Кроме того, в некоторых случаях после применения исправления его удаление может оказаться проблематичным.

Если адекватное тестирование исправлений невозможно, например из-за затрат или нехватки ресурсов, то следует рассмотреть возможность задержки его применения и оценить связанные с этим риски, основываясь на опыте, полученном от других пользователей. Может оказаться полезным использование ИСО/МЭК 27031 [14].

12.6.2 Ограничения на установку программного обеспечения

Мера обеспечения ИБ

Должны быть установлены и реализованы правила, регулирующие установку программного обеспечения пользователями.

Руководство по применению

Организация должна определить и закрепить строгую политику в отношении того, какие типы программного обеспечения могут устанавливать пользователи.

Следует исходить из принципа наименьших привилегий. В случае предоставления определенных привилегий пользователи могут иметь возможность устанавливать программное обеспечение. Организация должна определить, какие виды установок разрешены (например, обновления и исправления безопасности для существующего программного обеспечения) и какие виды запрещены (например, программное обеспечение, предназначенное только для личного использования, и неизвестное программное обеспечение, которое потенциально может быть вредоносным). Эти привилегии должны предоставляться с учетом ролей соответствующих пользователей.

Дополнительная информация

Неконтролируемая установка программного обеспечения на вычислительные устройства может привести к появлению уязвимостей, а затем к утечке информации, нарушению целостности или другим инцидентами ИБ, либо к нарушению прав на интеллектуальную собственность.

      12.7 Особенности аудита информационных систем

Цель: Минимизировать влияние аудиторской деятельности на функционирование систем, находящихся в эксплуатации.

12.7.1 Меры обеспечения информационной безопасности в отношении аудита информационных систем

Мера обеспечения ИБ

Требования к процессу регистрации событий [аудиту] и деятельности, связанной с контролем находящихся в эксплуатации систем, должны быть тщательно спланированы и согласованы для минимизации сбоев в бизнес-процессах.

Руководство по применению

Необходимо придерживаться следующих рекомендаций:

a) требования доступа к системам и данным для проведения аудита должны быть согласованы с соответствующим руководством;

b) область действия технического аудита должна быть согласована и проконтролирована;

c) аудиторские тесты должны быть ограничены доступом уровня «только на чтение» в отношении программного обеспечения и данных;

d) доступ, отличный от режима «только на чтение», должен быть разрешен только для изолированных копий системных файлов, которые должны быть уничтожены по завершении аудита или обеспечены соответствующей защитой, если существует необходимость сохранять такие файлы в соответствии с требованиями документации по аудиту;

e) требования к специальной и дополнительной обработке должны быть идентифицированы и согласованы;

f) аудиторские тесты, которые могут повлиять на доступность системы, следует проводить в нерабочее время;

g) любой доступ должен контролироваться и регистрироваться для создания прослеживаемости.

      13 Безопасность коммуникаций

      13.1 Менеджмент информационной безопасности сетей

Цель: Обеспечить защиту информации в сетях и в образующих их средствах обработки информации.

13.1.1 Меры обеспечения информационной безопасности сетей

Мера обеспечения ИБ

Сети должны управляться и контролироваться для обеспечения защиты информации в системах и приложениях.

Руководство по применению

Должны быть реализованы меры для обеспечения безопасности информации в сетях и защиты подключенных сервисов от несанкционированного доступа. В частности, следует учитывать следующее:

a) должны быть установлены обязанности и процедуры для управления сетевым оборудованием;

b) там, где это применимо, обязанности по эксплуатации сетей должны быть отделены от обязанностей по эксплуатации компьютеров (см. 6.1.2);

c) должны быть установлены специальные меры обеспечения ИБ для защиты конфиденциальности и целостности данных, передаваемых по сетям общего пользования или беспроводным сетям, и для защиты подключенных систем и приложений (раздел 10 и 13.2); могут потребоваться специальные меры для обеспечения доступности сетевых сервисов и подключенных компьютеров;

d) должна вестись соответствующая регистрация и мониторинг с целью фиксации и обнаружения действий, которые могут повлиять на ИБ или имеют отношение к ней;

e) действия по управлению должны быть тесно координированы как для того, чтобы оптимизировать обслуживание организации, так и для обеспечения того, чтобы меры обеспечения безопасности применялись согласованно в рамках всей инфраструктуры обработки информации;

f) системы в сетях должны проходить процедуру аутентификации;

g) подключение систем к сети должно быть ограничено.

Дополнительная информация

Дополнительную информацию о сетевой безопасности можно найти в ИСО/МЭК 27033 [15], [16], [17], [18], [19].

13.1.2 Безопасность сетевых сервисов

Мера обеспечения ИБ

Механизмы обеспечения безопасности, уровни обслуживания и требования к управлению для всех сетевых сервисов должны быть идентифицированы и включены в соглашения по сетевым сервисам независимо от того, будут ли они обеспечиваться силами организации или осуществляться с использованием аутсорсинга.

Руководство по применению

Следует определить и регулярно подвергать мониторингу способность поставщика сетевых сервисов безопасно управлять сервисами, определенными договором, а право проведения аудита должно быть согласовано.

Должны быть определены меры по обеспечению безопасности, необходимые для конкретных сервисов, такие как функции безопасности, уровни обслуживания и требования к управлению. Организация должна гарантировать, что поставщики сетевых сервисов реализуют эти меры.

Дополнительная информация

Сетевые сервисы включают в себя обеспечение соединений, сервисы частных сетей и сетей с расширенными возможностями, а также решения, касающиеся управления безопасностью сети, такие как межсетевые экраны и системы обнаружения вторжений. Эти сервисы могут варьироваться в диапазоне от простого предоставления неуправляемой полосы пропускания до сложных решений с дополнительными услугами.

Функциями безопасности сетевых сервисов могут быть:

a) технологии, применяемые для обеспечения безопасности сетевых сервисов, например аутентификация, шифрование и контроль сетевых подключений;

b) технические параметры, необходимые для безопасного подключения к сетевым сервисам в соответствии с правилами безопасности сетевых соединений;

c) процедуры использования сетевых сервисов, применяемые с целью ограничения доступа к сетевым сервисам или приложениям, где это необходимо.

13.1.3 Разделение в сетях

Мера обеспечения ИБ

Группы информационных сервисов, пользователей и информационных систем в сети должны быть разделены.

Руководство по применению

Одним из методов управления безопасностью больших сетей является разделение их на отдельные сетевые домены. Домены могут быть выбраны на основе уровней доверия (например, общедоступный домен, домен рабочих станций, домен сервера), на основе организационных подразделений (например, кадры, финансы, маркетинг) или на основе некоторой комбинации признаков (например, домен сервера, соединенный с несколькими организационными подразделениями). Разделение может быть выполнено физическим разделением на разные сети либо логическим (например, виртуальные частные сети).

Границы каждого домена должны быть четко определены. Доступ между сетевыми доменами может быть разрешен, но должен контролироваться на границе с использованием шлюза (например, межсетевого экрана, фильтрующего маршрутизатора). Критерии разделения сетей на домены и разрешение доступа через шлюзы должны основываться на оценке требований по безопасности каждого домена. Оценка должна проводиться в соответствии с политикой управления доступом (см. 9.1.1) и требованиями к доступу, в соответствии с ценностью и категорией обрабатываемой информации, а также с учетом относительной стоимости и влияния применяемой технологии шлюза на производительность.

Беспроводные сети требуют особого подхода в силу того, что их границы не являются достаточно определенными. В отношении чувствительных сегментов следует принять подход, при котором все запросы на беспроводной доступ следует рассматривать как внешние и отделять их от запросов внутренних сетей до тех пор, пока запрос не пройдет шлюз и не будет разрешен доступ к внутренним системам в соответствии с политикой обеспечения ИБ сетей (см. 13.1.1).

Технологии аутентификации, шифрования и управления доступом к сети на уровне пользователя, основанные на современных стандартах беспроводных сетей, при должной реализации могут быть достаточными для прямого подключения к внутренней сети организации.

Дополнительная информация

Сети часто выходят за границы организации, поскольку создаются деловые отношения, которые требуют объединения или совместного использования сетевого оборудования и устройств обработки информации. Такие действия могут увеличивать риск неавторизованного доступа к информационным системам организации, использующим сеть, причем в отношении некоторых из этих систем может потребоваться защита от пользователей другой сети в силу их чувствительности или критичности.

      13.2 Передача информации

Цель: Поддерживать безопасность информации, передаваемой как внутри организации, так и при обмене с любым внешним объектом и субъектом.

13.2.1 Политики и процедуры передачи информации

Мера обеспечения ИБ

Должны существовать формализованные политики и процедуры передачи информации, а также соответствующие меры, обеспечивающие безопасность информации, передаваемой с использованием всех видов средств связи.

Руководство по применению

Процедуры и меры обеспечения ИБ, которым необходимо следовать при использовании средств связи для передачи информации, должны учитывать следующее:

a) процедуры, предназначенные для защиты передаваемой информации от перехвата, копирования, модификации, перенаправления и уничтожения;

b) процедуры обнаружения и защиты от вредоносных программ, которые могут передаваться с использованием электронных средств связи (см. 12.2.1);

c) процедуры для защиты информации ограниченного доступа в электронном виде, передаваемой в форме вложения;

d) политику или руководства, определяющие допустимое использование средств связи (см. 8.1.3);

e) обязанности персонала, внешних сторон и любых иных пользователей не предпринимать действий, ставящих под угрозу организацию, например посредством клеветы, домогательств, неправомерного представления себя от лица организации, рассылки писем по цепочке, неавторизованных закупок и т.д.;

f) использование криптографических методов, например для защиты конфиденциальности, целостности и аутентичности информации (раздел 10);

g) руководства по срокам хранения и утилизации всей деловой переписки, включая сообщения, соответствующие национальному и местному законодательству и нормативным документам;

h) меры обеспечения ИБ и ограничения, связанные с использованием средств связи, например автоматическая пересылка электронной почты на внешние почтовые адреса;

i) рекомендации персоналу предпринимать меры предосторожности во избежание раскрытия конфиденциальной информации;

j) не оставлять сообщения, содержащие конфиденциальную информацию на автоответчиках, так как они могут быть прослушаны неавторизованными лицами, сохранены в системах общего пользования или некорректно записаны в результате ошибочного набора номера;

k) консультирование персонала о проблемах, связанных с использованием факсов и соответствующих услуг, а именно:

1) неавторизованный доступ к встроенным хранилищам сообщений для извлечения сообщений;

2) преднамеренное или случайное программирование машин на отправку сообщений на определенные номера;

3) отсылка документов и сообщений на неверный номер в результате ошибочного набора либо вызова сохраненного неверного номера.

Кроме того, персоналу следует напоминать, что не следует вести конфиденциальные разговоры в общественных местах или по небезопасным каналам связи, в открытых офисах и переговорных.

Услуги по передаче информации должны соответствовать всем релевантным требованиям законодательства (см. 18.1).

Дополнительная информация

Передача информации может осуществляться с использованием ряда различных типов средств связи, включая электронную почту, голосовую и факсимильную связь, а также видео.

Передача программного обеспечения может осуществляться различными способами, включая загрузку из Интернета и приобретение у поставщиков, продающих готовые продукты.

Следует учитывать юридические последствия, влияние на бизнес и безопасность, связанные с обменом электронными данными, электронной торговлей и электронной связью, а также требования к мерам обеспечения ИБ.

13.2.2 Соглашения о передаче информации

Мера обеспечения ИБ

Безопасная передача деловой информации между организацией и внешними сторонами должна быть определена соглашениями.

Руководство по применению

Соглашения по передаче информации должны включать в себя следующее:

a) обязанности руководства по контролю и уведомлению о передаче, отправке и получении;

b) процедуры для обеспечения прослеживаемости и неотказуемости;

c) минимальные требования технических стандартов для упаковки и передачи;

d) соглашения условного депонирования (эскроу);

е) стандарты по идентификации курьеров;

f) ответственность и обязательства в случае инцидентов ИБ, таких как потеря данных;

g) использование согласованной системы маркирования для информации ограниченного доступа, гарантирующей, что значение этой маркировки будет сразу же понято и что информация будет соответствующим образом защищена (см. 8.2);

h) технические стандарты для записи и чтения информации и программного обеспечения;

i) любые специальные меры обеспечения ИБ, которые требуются для защиты чувствительных элементов, например криптография (раздел 10);

j) поддержание цепочки сохранности информации в процессе передачи;

k) приемлемые уровни управления доступом.

Должны быть разработаны и поддерживаться политики, процедуры и стандарты по защите информации и физических носителей в процессе передачи (см. 8.3.3), на них следует ссылаться в соглашениях о передаче.

Часть любого соглашения, посвященного ИБ, должна отражать степень доступности деловой информации.

Дополнительная информация

Соглашения могут быть в электронном или бумажном виде и могут иметь форму официальных договоров. Конкретные механизмы, используемые для передачи конфиденциальной информации, должны быть согласованы для всех организаций и типов соглашений.

13.2.3 Электронный обмен сообщениями

Мера обеспечения ИБ

Следует обеспечивать соответствующую защиту информации при электронном обмене сообщениями.

Руководство по применению

Соображения по обеспечению ИБ электронных сообщений должны включать следующее:

a) защиту сообщений от несанкционированного доступа, изменения или отказа в обслуживании в соответствии с системой категорирования, принятой в организации;

b) обеспечение правильной адресации и передачи сообщения;

c) надежность и доступность сервиса;

d) правовые аспекты, например требования к электронным подписям;

е) получение одобрения до использования внешних общедоступных сервисов, например сервисов мгновенных сообщений, социальных сетей или сервисов обмена файлами;

f) более высокий уровень аутентификации при контроле доступа из общедоступных сетей.

Дополнительная информация

Существует много типов электронных сообщений, таких как электронная почта, обмен электронными данными и социальные сети, которые играют важную роль в деловых отношениях.

13.2.4 Соглашения о конфиденциальности или неразглашении

Мера обеспечения ИБ

Требования в отношении соглашений о конфиденциальности или неразглашении, отражающие потребности организации в обеспечении защиты информации, должны быть идентифицированы, документально оформлены и регулярно пересматриваться.

Руководство по применению

В соглашениях о конфиденциальности или неразглашении должно содержаться требование по защите конфиденциальной информации, выраженное юридическими терминами, имеющими исковую силу. Соглашения о конфиденциальности или неразглашении применимы к внешним сторонам или работникам организации. Содержание соглашения должно определяться с учетом типа другой стороны, предоставляемого доступа или обработки конфиденциальной информации. При определении требований к соглашениям о конфиденциальности или неразглашении необходимо учитывать следующее:

a) определение информации, подлежащей защите (например, конфиденциальной информации);

b) ожидаемый срок действия соглашения, включая случаи, когда конфиденциальность должна обеспечиваться в течение неопределенного времени;

c) действия, необходимые при расторжении соглашения;

d) обязанности и действия лиц, подписавших соглашение, во избежание несанкционированного раскрытия информации;

e) право собственности на информацию, коммерческую тайну и интеллектуальную собственность и то, как это связано с защитой конфиденциальной информации;

f) разрешенное использование конфиденциальной информации и права лиц, подписавших соглашение, в отношении использования информации;

g) право на аудит и мониторинг деятельности, связанной с конфиденциальной информацией;

h) процесс уведомления и сообщения о несанкционированном раскрытии или утечке конфиденциальной информации;

i) условия, при которых информация должна быть возвращена или уничтожена в случае прекращения действия соглашения;

j) предполагаемые действия, которые должны быть предприняты в случае нарушения соглашения.

Исходя из требований ИБ организации, может потребоваться добавление других элементов в соглашения о конфиденциальности или неразглашении.

Соглашения о конфиденциальности и неразглашении должны соответствовать всем применимым законам и нормативным документам, под юрисдикцию которых они подпадают (см. 18.1).

Требования соглашений о конфиденциальности и неразглашении следует пересматривать периодически и в тех случаях, когда происходят изменения, затрагивающие эти требования.

Дополнительная информация

Соглашения о конфиденциальности и неразглашении защищают информацию организации, а также надежным и правомочным образом информируют лиц, подписавших соглашение, об их ответственности за защиту, использование и разглашение информации.

В зависимости от различных обстоятельств организации могут потребоваться различные формы соглашений о конфиденциальности или неразглашении.

      14 Приобретение, разработка и поддержка систем

      14.1 Требования к безопасности информационных систем

Цель: Обеспечить уверенность в том, что ИБ является неотъемлемой частью информационных систем на протяжении всего их жизненного цикла и включает требования к информационным системам, предоставляющим услуги с использованием сетей общего пользования.

14.1.1 Анализ и спецификация требований информационной безопасности

Мера обеспечения ИБ

Требования, относящиеся к ИБ, должны быть включены в перечень требований для новых информационных систем или для усовершенствования существующих информационных систем.

Руководство по применению

Требования ИБ должны быть идентифицированы с использованием различных методов, таких как выделение требований соответствия из политик и регламентов, моделирование угроз, анализ инцидентов или использование порогов уязвимости. Результаты идентификации должны быть задокументированы и рассмотрены всеми заинтересованными сторонами.

Требования и меры обеспечения ИБ должны отражать ценность информации (см. 8.2) и потенциальное негативное влияние на бизнес, которое может быть вызвано отсутствием надлежащей защиты.

Идентификация и управление требованиями ИБ и связанными с этими процессами должны быть интегрированы в проекты информационных систем на ранних стадиях. Раннее рассмотрение требований ИБ, например на этапе проектирования, может дать более эффективные и менее затратные решения.

Требования ИБ также должны учитывать:

a) требуемый уровень доверия в отношении идентификационной информации пользователей для установления требований к аутентификации пользователей;

b) процессы предоставления доступа как для пользователей, так и для привилегированных или технических пользователей;

c) информирование пользователей и операторов об их обязанностях и ответственности;

d) необходимый уровень защиты в отношении затронутых активов, в частности в отношении доступности, конфиденциальности и целостности;

e) требования, вытекающие из бизнес-процессов, такие как ведение журнала и мониторинг транзакций, требования по обеспечению неотказуемости;

f) требования, предписанные другими мерами обеспечения ИБ, например интерфейсы для систем регистрации, мониторинга или обнаружения утечки данных.

Для приложений, которые предоставляют услуги через общедоступные сети или осуществляют транзакции, следует рассмотреть меры обеспечения ИБ, которые приведены в 14.1.2 и 14.1.3.

В случае приобретения продукта следует придерживаться формального процесса тестирования и приобретения. В договорах с поставщиком должны быть учтены установленные требования безопасности. Если функциональные возможности обеспечения безопасности в предлагаемом продукте не удовлетворяют указанным требованиям, порождаемый этим риск и связанные с ним меры должны быть рассмотрены до того, как продукт будет приобретен.

Имеющееся руководство по настройке мер обеспечения безопасности продукта, соответствующее финальному стеку программного обеспечения/сервисов системы, должно быть оценено и выполнено.

Должны быть определены критерии приемки продуктов, например с точки зрения их функциональности, что даст гарантию того, что установленные требования безопасности будут выполнены. Продукты должны быть оценены по этим критериям до их приобретения. Дополнительный функционал продукта также должен быть рассмотрен, чтобы убедиться, что он не порождает дополнительных неприемлемых рисков.

Дополнительная информация

ИСО/МЭК 27005 [11] и ИСО 31000 [27] предоставляют руководство по применению процессов управления рисками для идентификации мер обеспечения ИБ и выполнения требований.

14.1.2 Обеспечение безопасности прикладных сервисов, предоставляемых с использованием сетей общего пользования

Мера обеспечения ИБ

Информация, используемая в прикладных сервисах и передаваемая по сетям общего пользования, должна быть защищена от мошеннической деятельности, оспаривания договоров, а также несанкционированного раскрытия и модификации.

Руководство по применению

ИБ прикладных сервисов, проходящих через общедоступные сети, следует обеспечивать исходя из следующих соображений:

a) уровень доверия, который требует каждая сторона в отношении друг друга, например посредством аутентификации;

b) процессы авторизации, связанные с тем, кто может утверждать содержание, выпускать или подписывать ключевые деловые документы;

c) обеспечение того, чтобы взаимодействующие стороны были полностью проинформированы о своих правах на предоставление и использование сервиса;

d) определение и соблюдение требований в отношении конфиденциальности, целостности, подтверждения отправки и получения ключевых документов, а также невозможности отказа от совершенных сделок, например связанных с процессами заключения контрактов и проведения тендеров;

e) уровень доверия, необходимый для целостности ключевых документов;

f) требования по защите любой конфиденциальной информации;

g) конфиденциальность и целостность любых операций с заказом, платежной информации, адреса доставки и подтверждения получения;

h) степень проверки платежной информации, предоставленной клиентом;

i) выбор наиболее подходящей формы расчета для защиты от мошенничества;

j) уровень защиты, необходимый для сохранения конфиденциальности и целостности информации о заказе;

k) предотвращение потери или дублирования информации об операции;

I) ответственность за мошеннические операции;

m) страховые требования.

Многие из вышеперечисленных соображений могут быть выполнены с применением криптографических мер обеспечения ИБ (раздел 10), принимая во внимание требования законодательства (раздел 18, особенно 18.1.5 для законодательства о криптографии).

Механизмы предоставления услуг между участниками должны быть закреплены документально оформленным соглашением, в котором обе стороны соглашаются с условиями предоставления сервисов, включая детали авторизации (перечисление b).

Следует учитывать требования устойчивости к атакам, которые могут включать в себя требования по защите используемых серверов приложений или обеспечению доступности сетевых соединений, необходимых для предоставления сервиса.

Дополнительная информация

Приложения, доступные через сети общего пользования, подвержены целому ряду угроз, таких как мошеннические действия, нарушение условий договора или публичное разглашение информации. Поэтому обязательным здесь является детальная оценка риска и правильный выбор мер обеспечения ИБ. Необходимые меры обеспечения ИБ часто включают в себя криптографические методы для аутентификации и защиты данных при передаче.

Прикладные сервисы могут использовать безопасные методы аутентификации, например использование криптографии с открытым ключом и электронных подписей (раздел 10) для снижения рисков. Кроме того, при необходимости, могут быть задействованы доверенные третьи стороны.

14.1.3 Защита транзакций прикладных сервисов

Мера обеспечения ИБ

Информацию, используемую в транзакциях прикладных сервисов, следует защищать для предотвращения неполной передачи, ложной маршрутизации, несанкционированного изменения, раскрытия, дублирования или воспроизведения сообщений.

Руководство по применению

Вопросы безопасности для транзакций прикладных сервисов должны включать следующее:

a) использование электронных подписей каждой из сторон, участвующих в транзакции;

b) все аспекты транзакции, то есть обеспечение того, что:

1) секретная аутентификационная информация пользователей с каждой стороны проверена и действительна;

2) транзакция остается конфиденциальной;

3) сохраняется конфиденциальность всех вовлеченных сторон;

c) канал связи между всеми вовлеченными сторонами защищен;

d) протоколы, используемые для связи между всеми вовлеченными сторонами, защищены;

e) обеспечение того, чтобы хранение деталей транзакции находилось за пределами какой-либо общедоступной среды, например в хранилище интрасети организации, которое не доступно непосредственно из сети Интернет;

f) если используется доверенный орган (например, для целей выдачи и поддержки электронных подписей или цифровых сертификатов), обеспечение безопасности интегрируется и становится частью процесса управления сертификатами/подписями на протяжении всего жизненного цикла такого процесса.

Дополнительная информация

Объем принятых мер обеспечения ИБ должен соответствовать уровню риска, связанного с каждой формой транзакции прикладных сервисов.

Транзакции должны соответствовать юридическим и нормативным требованиям той юрисдикции, где их формируют, обрабатывают, завершают или хранят.

      14.2 Безопасность в процессах разработки и поддержки

Цель: Обеспечить уверенность в том, что меры обеспечения ИБ спроектированы и внедрены на всех стадиях жизненного цикла разработки информационных систем.

14.2.1 Политика безопасной разработки

Мера обеспечения ИБ

Правила разработки программного обеспечения и систем должны быть установлены и применены к разработкам в рамках организации.

Руководство по применению

Безопасная разработка — это требование для создания безопасного сервиса, архитектуры, программного обеспечения и системы. В рамках политики безопасной разработки должны быть учтены следующие аспекты:

a) безопасность среды разработки;

b) руководство по безопасности в жизненном цикле разработки программного обеспечения:

1) безопасность в методологии разработки программного обеспечения;

2) правила по безопасному программированию для каждого используемого языка программирования;

c) требования безопасности на этапе проектирования;

d) контрольные точки по проверке безопасности в рамках основных этапов проекта;

e) безопасные репозитории;

f) безопасность в управлении версиями;

g) необходимые знания по безопасности приложений;

h) способность разработчиков избегать, находить и исправлять уязвимости.

Методы безопасного программирования должны применяться как в отношении новых разработок, так и в случае повторного использования кода, при разработке которого использованы неизвестные стандарты или использованные стандарты не соответствуют лучшим практикам. Следует рассмотреть и, в случае необходимости, сделать обязательными для применения стандарты безопасного программирования. Разработчики должны быть обучены применению этих стандартов и тестированию, а анализ кода должен служить проверкой их использования.

Если разработка осуществляется на аутсорсинге, организация должна получить гарантии того, что внешняя сторона соблюдает правила по безопасной разработке (см. 14.2.7).

Дополнительная информация

Разработка также может вестись внутри самих приложений, например в офисных приложениях, скриптах, браузерах и базах данных.

14.2.2 Процедуры управления изменениями системы

Мера обеспечения ИБ

Необходимо управлять изменениями в системах в течение жизненного цикла разработки посредством применения формализованных процедур управления изменениями.

Руководство по применению

Формальные процедуры управления изменениями должны быть задокументированы и применены для обеспечения целостности системы, приложений и продуктов, начиная с ранних этапов проектирования и до всех последующих действий по поддержке. Внедрение новых систем и значительные изменения в существующих системах должны происходить в соответствии с формальным процессом документирования, спецификации, тестирования, контроля качества и управляемой реализации.

Этот процесс должен включать оценку риска, анализ последствий от изменений и определение необходимых мер обеспечения ИБ, а также должен гарантировать, что существующие меры не будут нарушены, что программистам поддержки предоставлен доступ только к тем частям системы, которые необходимы для их работы, и что получено формальное согласие на любые изменения и их одобрение.

Везде, где это практически возможно, процедуры управления изменениями для приложений и среды эксплуатации должны быть объединены (см. 12.1.2). Процедуры управления изменениями должны включать (но не ограничиваться этим) следующее:

a) ведение учета согласованных уровней разрешений;

b) обеспечение внесения изменений авторизованными пользователями;

c) пересмотр процедур управления и целостности для гарантии того, что они не будут нарушены изменениями;

d) идентификация всего программного обеспечения, информации, объектов базы данных и аппаратного обеспечения, которые требуют изменений;

e) выявление и проверка критического с точки зрения безопасности кода для минимизации вероятности реализации известных ошибок программирования;

f) получение официального одобрения на предлагаемые изменения до начала работ;

g) обеспечение того, чтобы авторизованные пользователи одобрили все изменения до их реализации;

h) обеспечение того, чтобы набор системной документации был обновлен по завершении каждого изменения, а старая документация архивировалась или удалялась;

i) поддержание контроля версий всех обновлений программного обеспечения;

j) ведение записей всех запросов на изменение;

k) обеспечение того, чтобы эксплуатационная документация (см. 12.1.1) и пользовательские процедуры подвергались изменениям по мере необходимости и оставались актуальными;

I) обеспечение того, чтобы внедрение изменений происходило в согласованное время и не нарушало вовлеченные бизнес-процессы.

Дополнительная информация

Так же как изменение программного обеспечения может повлиять на среду эксплуатации, так и наоборот.

Общепринятая практика включает в себя тестирование нового программного обеспечения в среде, отделенной как от среды эксплуатации, так и от среды разработки (см. 12.1.4). Это позволит иметь средства управления над новым программным обеспечением и обеспечивает дополнительную защиту эксплуатационной информации, которая используется в целях тестирования. Это относится к пакетам обновлений и исправлений, а также к прочим типам обновлений.

В тех случаях, где рассматривается автоматическое применение обновлений, риск в отношении целостности и доступности системы должен быть сопоставлен с преимуществами быстрого развертывания обновлений. Автоматические обновления не должны использоваться в критических системах, так как некоторые из них могут привести к сбою критических приложений.

14.2.3 Техническая экспертиза приложений (прикладных программ) после изменений операционной платформы

Мера обеспечения ИБ

При внесении изменений в операционные платформы критически важные для бизнеса приложения должны быть проверены и протестированы, чтобы обеспечить уверенность в отсутствии неблагоприятного воздействия на деятельность или безопасность организации.

Руководство по применению

Этот процесс должен охватывать:

a) пересмотр мер защиты приложения и процедур целостности для гарантии того, что они не будут нарушены изменениями в эксплуатируемой среде;

b) обеспечение своевременного уведомления об изменениях эксплуатируемой платформы с учетом времени проведения соответствующих тестов и проверки перед внедрением;

c) обеспечение внесения соответствующих изменений в планы обеспечения непрерывности бизнеса (раздел 17).

Дополнительная информация

Эксплуатируемые платформы включают в себя операционные системы, базы данных и связующее программное обеспечение. Меры обеспечения ИБ также должны применяться для процесса изменения приложений.

14.2.4 Ограничения на изменения пакетов программ

Мера обеспечения ИБ

Следует избегать модификаций пакетов программ, ограничиваться необходимыми изменениями и строго контролировать все изменения.

Руководство по применению

Насколько это возможно и практически осуществимо, пакеты программного обеспечения, приобретаемые у поставщика, следует использовать без изменений. Если требуется модифицировать пакет программ, необходимо учитывать следующее:

a) возможен риск нарушения встроенных средств контроля целостности;

b) должно ли быть получено согласие поставщика;

c) возможность получения необходимых изменений от поставщика в виде стандартных обновлений программы;

d) возможные последствия в случае, если организация станет ответственной за последующее сопровождение программного обеспечения в результате внесенных изменений;

e) совместимость с другим используемым программным обеспечением.

При необходимости внесения изменений оригинальное программное обеспечение должно быть сохранено, а изменения должны применяться к четко определенной копии. Процесс управления обновлениями программного обеспечения должен быть реализован для обеспечения того, чтобы для всего разрешенного программного обеспечения устанавливались самые последние утвержденные исправления и обновления (см. 2.6.1). Все изменения должны быть полностью протестированы и задокументированы, чтобы при необходимости их можно было применить к будущим обновлениям программного обеспечения. При необходимости изменения должны быть проверены и подтверждены независимым органом по оценке.

14.2.5 Принципы безопасного проектирования систем

Мера обеспечения ИБ

Принципы безопасного проектирования систем должны быть установлены, задокументированы, поддерживаться и применяться к любым работам по реализации информационной системы.

Руководство по применению

Процедуры безопасного проектирования информационных систем, основанные на указанных выше принципах, должны быть установлены, задокументированы и применены к внутренним процессам по проектированию информационных систем. Безопасность должна проектироваться на всех уровнях архитектуры (бизнес, данные, приложения и технологии), чтобы сбалансировать потребность в ИБ и удобстве. Новые технологии должны быть проанализированы на предмет угроз безопасности, а решения должны быть рассмотрены с точки зрения известных шаблонов атак.

Эти принципы и установленные процедуры проектирования должны регулярно пересматриваться, чтобы гарантировать, что они эффективно способствуют развитию стандартов безопасности в процессе проектирования. Их также следует регулярно пересматривать, чтобы обеспечить их актуальность с точки зрения борьбы с любыми потенциальными новыми угрозами и их пригодности к постоянно улучшающимся применяемым технологиям и решениям.

Установленные принципы безопасного проектирования должны применяться, по возможности, к информационным системам, находящимся на аутсорсинге, при помощи обязательных соглашений и контрактов между организацией и поставщиком. Организация должна подтвердить, что строгость принципов безопасного проектирования сопоставима с ее собственными.

Дополнительная информация

Процедуры разработки приложений должны применять методы безопасного проектирования при разработке приложений, имеющих интерфейсы ввода и вывода. Методы безопасного проектирования предоставляют методическую основу для методов аутентификации пользователей, безопасного управления сессиями и валидации данных, санитизации и удаления отладочной информации.

14.2.6 Безопасная среда разработки

Мера обеспечения ИБ

Организация должна установить и надлежащим образом защищать безопасные среды разработки, используемые для разработки и интеграции систем на всех стадиях жизненного цикла разработки системы.

Руководство по применению

Безопасная среда разработки включает в себя людей, процессы и технологии, связанные с разработкой и интеграцией систем.

Организации должны оценивать риски, связанные с определенными действиями по разработке систем, и формировать безопасные среды разработки для конкретных работ по разработке систем, учитывая:

a) информацию ограниченного доступа, подлежащую обработке, хранению и передаче системой;

b) применимые внешние и внутренние требования, например из нормативных актов или политик;

c) меры обеспечения ИБ, уже внедренные организацией для обеспечения разработки систем;

d) надежность персонала, работающего в среде (см. 7.1.1);

e) степень аутсорсинга работ, связанных с разработкой систем;

f) необходимость разделения различных сред разработки;

g) меры разграничения доступа к среде разработки;

h) мониторинг изменений среды и хранимого в ней кода;

i) резервные копии хранятся в безопасных удаленных местах;

j) контроль за перемещением данных из и в среду разработки.

Как только для конкретной среды разработки определен уровень защиты, организация должна задокументировать соответствующие процессы в процедурах безопасной разработки и довести их до сведения всех лиц, которые в них нуждаются.

14.2.7 Разработка с использованием аутсорсинга

Мера обеспечения ИБ

Организация должна осуществлять надзор за разработкой систем, выполняемой подрядчиками, и ее мониторинг.

Руководство по применению

В тех случаях, когда разработка системы осуществляется сторонними организациями, для всей цепочки поставок организации необходимо учесть следующее:

a) лицензионные соглашения, права на код и интеллектуальную собственность, связанные с находящимися на аутсорсинге разработками (см. 18.1.2);

b) договорные требования к безопасным методам проектирования, программирования и тестирования (см. 14.2.1);

c) предоставление утвержденной модели угроз внешнему разработчику;

d) приемочные испытания на качество и точность результатов;

e) предоставление доказательств того, что были применены пороговые критерии безопасности для установления минимально приемлемых уровней защищенности и конфиденциальности;

f) предоставление доказательств того, что было выполнено тестирование в достаточном объеме, чтобы подтвердить отсутствие преднамеренного или непреднамеренного вредоносного содержимого в поставляемых продуктах;

g) предоставление доказательств того, что было проведено достаточное тестирование для защиты от известных уязвимостей;

h) механизмы условного депонирования, например, если исходный код больше недоступен;

i) закрепленное в договоре право на аудит процессов и мер разработки;

j) действующая документация среды сборки, используемая для создания конечных продуктов;

k) организация несет ответственность за соблюдение действующего законодательства и проверку эффективности мер обеспечения ИБ.

Дополнительная информация

Дополнительную информацию об отношениях с поставщиками можно найти в ИСО/МЭК 27036 [21], [22], [23].

14.2.8 Тестирование безопасности систем

Мера обеспечения ИБ

Тестирование функциональных возможностей безопасности должно осуществляться в процессе разработки.

Руководство по применению

Новые и обновляемые системы требуют тщательного тестирования и проверки в ходе процесса разработки, включая подготовку подробного графика работ, а также входных данных и ожидаемых результатов при различных условиях тестирования. Для собственных разработок такие тесты должны первоначально выполняться командой разработки. Затем должно быть проведено независимое приемочное тестирование (как для внутренних, так и для находящихся на аутсорсинге разработок), чтобы убедиться, что система работает только так, как и ожидается (см. 14.1.1, 14.2.9). Глубина тестирования должна быть пропорциональна важности и характеру системы. (Внесена техническая поправка Сог.2:2015).

14.2.9 Приемо-сдаточные испытания системы

Мера обеспечения ИБ

Для новых информационных систем, обновлений и новых версий должны быть разработаны программы приемо-сдаточных испытаний и установлены связанные с ними критерии.

Руководство по применению

Приемочные испытания должны включать в себя проверку выполнения требований по ИБ (см. 14.1.1, 14.1.2) и соблюдение правил безопасной разработки системы (см. 14.2.1). Тестирование также должно проводиться в отношении заимствованных компонентов и интегрированных систем. Организации могут использовать автоматизированные инструменты, такие как анализаторы кода или сканеры уязвимостей, и должны гарантировать исправление связанных с безопасностью дефектов.

Испытания следует проводить в реалистичной среде тестирования, чтобы гарантировать надежность результатов и невозможность создания системой дополнительных уязвимостей в среде организации.

      14.3 Тестовые данные

Цель: Обеспечить защиту данных, используемых для тестирования.

14.3.1 Защита тестовых данных

Мера обеспечения ИБ

Тестовые данные следует тщательно выбирать, защищать и контролировать.

Руководство по применению

Следует избегать использования данных из эксплуатируемой среды, содержащих персональные данные или любую другую конфиденциальную информацию, в целях тестирования. Если для целей тестирования используется такая информация, все конфиденциальные данные и содержимое должно быть защищено путем удаления или модификации (см. ИСО/МЭК 29101 [26]).

Для защиты эксплуатационных данных, используемых в целях тестирования, должны применяться следующие рекомендации:

a) процедуры контроля доступа, которые применяются к эксплуатируемым прикладным системам, должны также применяться к тестовым прикладным системам;

b) необходимо запрашивать разрешение каждый раз, когда эксплуатируемые данные копируются в тестовую среду;

c) информация из эксплуатируемой среды должна быть удалена из тестовой среды сразу после завершения тестирования;

d) копирование и использование информации из эксплуатируемой среды должно регистрироваться для обеспечения аудита.

Дополнительная информация

Системные и приемочные испытания обычно требуют значительных объемов тестовых данных, максимально приближенных к эксплуатационным.

      15 Взаимоотношения с поставщиками

      15.1 Информационная безопасность во взаимоотношениях с поставщиками

Цель: Обеспечить защиту активов организации, доступных поставщикам.

15.1.1 Политика информационной безопасности во взаимоотношениях с поставщиками

Мера обеспечения ИБ

Требования ИБ, направленные на снижение рисков, связанных с доступом поставщиков к активам организации, должны быть согласованы с поставщиком и задокументированы.

Руководство по применению

В своей политике организация должна определить и назначить меры обеспечения ИБ, которые относятся к доступу поставщиков к информации организации. Эти меры должны учитывать процессы и процедуры, которые должны выполняться организацией, а также те процессы и процедуры, которые организация должна требовать выполнять от поставщика, включая:

a) определение и документирование типов поставщиков, например ИТ-услуги, логистические услуги, финансовые услуги, компоненты ИТ-инфраструктуры, которым организация будет предоставлять доступ к своей информации;

b) стандартизированный процесс и жизненный цикл для управления отношениями с поставщиками;

c) определение типов доступа к информации, которые будут предоставлены различным типам поставщиков, а также мониторинг и контроль доступа;

d) минимальные требования по ИБ для каждой категории информации и типа доступа, учитывающие деловые потребности и требования организации, а также ее профиль рисков, которые будут служить основой для соглашений уже с конкретным поставщиком;

e) процессы и процедуры для контроля соблюдения установленных требований по ИБ для каждого типа поставщика и типа доступа, включая проверку третьей стороной и проверку продукта;

f) правильность и полноту мер обеспечения ИБ для обеспечения целостности информации или обработки информации, проводимой любой из сторон;

g) виды обязательств, применимых к поставщикам для защиты информации организации;

h) обработку инцидентов и непредвиденных обстоятельств, связанных с доступом поставщиков, включая обязанности как организации, так и поставщиков;

i) способность к восстановлению и, если необходимо, меры по восстановлению и устранению непредвиденных обстоятельств для обеспечения доступности информации или обработки информации, предпринимаемые любой из сторон;

j) обучение персонала организации, участвующего в закупках, действующим политикам, процессам и процедурам;

k) обучение персонала организации, взаимодействующего с персоналом поставщика, относительно соответствующих правил взаимодействия и поведения в зависимости от типа поставщика и уровня доступа поставщика к системам и информации организации;

I) условия, при которых требования и меры обеспечения ИБ будут включены в соглашение, подписанное обеими сторонами;

m) управление необходимой передачей информации, устройств обработки информации и чем-либо еще, нуждающимся в передаче, и гарантию того, что безопасность обеспечивается в течение всего периода передачи.

Дополнительная информация

При ненадлежащем управлении ИБ информация может подвергаться риску со стороны поставщиков. Должны быть определены и выполняться меры обеспечения ИБ для управления доступом поставщиков к средствам обработки информации. Например, если существует особая необходимость в сохранении конфиденциальности информации, может заключаться соглашение о неразглашении. Другой пример защиты данных от рисков — когда соглашение с поставщиками включает в себя вопросы передачи информации или доступа к информации из-за границы. Организация должна осознавать, что ответственность за соблюдение законодательства и контрактных обязательств по защите информации лежит на самой организации.

15.1.2 Рассмотрение вопросов безопасности в соглашениях с поставщиками

Мера обеспечения ИБ

Все соответствующие требования по ИБ должны быть установлены и согласованы с каждым поставщиком, который может получить доступ к информации организации, обрабатывать, хранить, передавать информацию или предоставлять соответствующие компоненты ИТ-инфраструктуры.

Руководство по применению

Соглашения с поставщиками должны быть разработаны и задокументированы, чтобы гарантировать, что между организацией и поставщиком нет недопонимания относительно взаимных обязательств по выполнению соответствующих требований по ИБ.

Для выполнения установленных требований ИБ следует рассмотреть включение в соглашения следующих условий:

a) описание предоставляемой информации или информации, к которой предоставляется доступ, а также методов предоставления информации или получения доступа к ней;

b) категории информации в соответствии с системой категорирования организации (см. 8.2); сопоставление, при необходимости, системы категорирования организации с системой категорирования поставщика;

c) законодательные и нормативные требования, включая требования по защите данных, прав на интеллектуальную собственность и авторских прав, а также описание того, как будет обеспечено их соблюдение;

d) обязательства каждой стороны договора по осуществлению согласованного набора мер обеспечения ИБ, включая управление доступом, анализ производительности, мониторинг, отчетность и аудит;

e) правила приемлемого использования информации, включая неприемлемое использование, в случае необходимости;

f) точный перечень персонала поставщика, который авторизован на доступ к информации или получение информации организации, либо процедуры или условия для назначения и аннулирования прав на доступ к информации или получение информации организации персоналом поставщика;

g) политики ИБ, относящиеся к конкретному договору;

h) требования и процедуры по управлению инцидентами (особенно уведомление и совместная работа по устранению последствий инцидентов);

i) требования к обучению и осведомленности о конкретных процедурах и требования к ИБ, например для реагирования на инциденты, процедуры авторизации;

j) соответствующие регламенты для субподряда, включая меры обеспечения ИБ, которые должны выполняться;

k) соответствующие партнеры по соглашению, включая контактное лицо по вопросам ИБ;

I) требования к предварительной проверке персонала поставщика, если таковые установлены, включая обязанности по проведению процедур предварительной проверки и информирования в случае, когда проверка не была завершена или ее результаты дают основания для сомнений или опасений;

m) право на аудит процессов поставщика и осуществление мер обеспечения ИБ, связанных с соглашением;

n) процессы устранения дефектов и разрешения конфликтов;

o) обязательство поставщика по периодическому предоставлению независимого отчета об эффективности мер обеспечения ИБ и соглашения о своевременном решении соответствующих проблем, упомянутых в отчете;

p) обязательства поставщика по соблюдению требований безопасности организации.

Дополнительная информация

Соглашения могут значительно различаться для разных организаций и разных типов поставщиков. В связи с этим следует уделить внимание тому, чтобы учесть все актуальные риски и требования ИБ. Соглашения с поставщиками могут также допускать участие других сторон (например, субподрядчиков).

В соглашении необходимо учесть процедуры обеспечения непрерывности производственных процессов в случае, если поставщик не в состоянии поставлять свои продукты или услуги, во избежание любых задержек из-за замены продуктов и услуг.

15.1.3 Цепочка поставок информационно-коммуникационных технологий

Мера обеспечения ИБ

Соглашения с поставщиками должны содержать требования по рассмотрению рисков ИБ, связанных с цепочкой поставок продуктов и услуг информационно-коммуникационных технологий.

Руководство по применению

Относительно безопасности цепочек поставок для включения в соглашения с поставщиками должны быть рассмотрены следующие положения:

a) определение требований ИБ, применимых к закупкам продуктов или услуг в области информационно-коммуникационных технологий, в дополнение к общим требованиям ИБ, относящимся к отношениям с поставщиками;

b) для услуг в области информационно-коммуникационных технологий требуется, чтобы поставщики распространяли требования безопасности организации на всю цепочку поставки, если поставщик привлекает подрядчиков для выполнения части услуг в области информационно-коммуникационных технологий, оказываемых организации;

c) для продуктов в области информационно-коммуникационных технологий требуется, чтобы поставщики распространяли соответствующие процедуры, связанные с безопасностью, на всю цепочку поставки, если эти продукты включают в себя компоненты, закупаемые у других поставщиков;

d) выполнение процесса мониторинга и подходящих методов для подтверждения того, что поставляемые продукты и услуги в области информационно-коммуникационных технологий соответствуют заявленным требованиям безопасности;

e) выполнение процесса определения компонентов продукта или услуги, которые являются критически важными для поддержания функциональности и следовательно требуют повышенного внимания и изучения, если произведены за пределами организации, особенно если первичный поставщик передает на аутсорсинг производство каких-то элементов продукта или услуги другим поставщикам;

f) получение уверенности в том, что критически важные компоненты и их происхождение могут быть прослежены по всей цепочке поставки;

g) получение уверенности в том, что поставляемые продукты в области информационно-коммуникационных технологий функционируют должным образом без каких-либо непредусмотренных или нежелательных функций;

h) определение правил обмена информацией, касающихся цепочки поставки и любых потенциальных проблем и компромиссов между организацией и поставщиками;

i) выполнение конкретных процессов управления жизненным циклом и доступностью компонентов информационно-коммуникационных технологий и связанными с ними рисками безопасности. Это включает в себя управление рисками, связанными с тем, что компоненты более не доступны в силу того, что их поставщики прекратили свою деятельность или прекратили поставку этих компонентов по причине развития технологий.

Дополнительная информация

Конкретные методы управления рисками в цепочке поставки информационно-коммуникационных технологий основаны на высокоуровневых процедурах обеспечения общей ИБ, качества, управления проектами и разработки систем, но не заменяют их.

Организациям рекомендуется работать с поставщиками для понимания цепочки поставки информационно-коммуникационных технологий и любых вопросов, оказывающих значительное влияние на поставляемые продукты и услуги. Организации могут влиять на методы обеспечения ИБ в цепочке поставок информационно-коммуникационных технологий, четко определяя в соглашениях со своими поставщиками вопросы, которые должны решаться другими поставщиками в цепочке поставок информационно-коммуникационных технологий.

Цепочка поставок информационно-коммуникационных технологий, как указано здесь, включает в себя услуги облачных вычислений.

      15.2 Управление услугами, предоставляемыми поставщиком

Цель: Поддерживать согласованный уровень ИБ и предоставления услуги в соответствующих соглашениях с поставщиками.

15.2.1 Мониторинг и анализ услуг поставщика

Мера обеспечения ИБ

Организации должны регулярно проводить мониторинг, проверку и аудит деятельности поставщика по предоставлению услуг.

Руководство по применению

Мониторинг и анализ услуг, предоставляемых поставщиком, должны обеспечивать уверенность в том, что положения и условия, касающиеся ИБ, отраженные в соглашениях, выполняются и что инциденты и проблемы в области ИБ решаются должным образом.

Это должно реализовываться при управлении услугами через процесс взаимодействия между организацией и поставщиком, чтобы:

a) осуществлять мониторинг уровней предоставления услуг с целью проверки соблюдения условий соглашений;

b) анализировать отчеты об услугах, подготовленные поставщиком, и организовывать регулярные рабочие встречи, как это определено соглашениями;

c) проводить аудиты поставщиков вместе с анализом отчетов независимых аудиторов, если они есть, и осуществлять последующие действия по выявленным проблемам;

d) предоставлять информацию об инцидентах ИБ и анализировать эту информацию в соответствии с требованиями соглашений и любых вспомогательных методических рекомендаций и процедур;

e) анализировать контрольные записи поставщиков и записи о событиях безопасности, эксплуатационных проблемах, сбоях, обнаруженных ошибках и нарушениях, связанных с поставляемой услугой;

f) решать любые выявленные проблемы и управлять ими;

g) анализировать в разрезе аспектов ИБ отношения поставщика с его подрядчиками;

h) гарантировать, что поставщик сохраняет достаточную способность обслуживания согласно работоспособным планам, разработанным для обеспечения согласованных уровней непрерывности обслуживания при значительных сбоях и аварийных ситуациях (раздел 17).

Ответственность за управление отношениями с поставщиками следует возлагать на специально назначенное лицо или группу по управлению услугами. Кроме того, организация должна обеспечить, чтобы поставщики установили обязанности по анализу соответствия и обеспечению выполнения требований соглашения. Должны быть выделены достаточные ресурсы с необходимыми техническими навыками для мониторинга того, что требования соглашения, в частности требования ИБ, выполняются. Необходимо предпринимать соответствующие действия при обнаружении недостатков в оказании услуг.

Организация должна поддерживать достаточный общий контроль и прозрачность всех аспектов безопасности в отношении информации ограниченного доступа или устройств обработки информации, к которым поставщик имеет доступ, использует их или управляет ими. Организация должна поддерживать прозрачность действий, связанных с безопасностью, таких как управление изменениями, выявление уязвимостей, а также составление отчетов об инцидентах ИБ и реагирование на них с помощью установленного процесса оповещения.

15.2.2 Управление изменениями услуг поставщика

Мера обеспечения ИБ

Требуется управлять изменениями в предоставляемых поставщиками услугах, включая поддержку и улучшение существующих политик, процедур, а также мер обеспечения ИБ, с учетом категории информации бизнеса, задействованных систем и процессов, а также результатов переоценки рисков ИБ.

Руководство по применению

Должны быть приняты во внимание следующие аспекты:

a) изменения в соглашениях с поставщиками;

b) изменения, проводимые организацией, для реализации:

1) улучшения текущих предлагаемых услуг;

2) разработки любых новых прикладных программ и систем;

3) изменения или обновления политик и процедур организации;

4) новых или измененных мер для устранения инцидентов ИБ и повышения безопасности;

c) изменения в услугах поставщика для реализации:

1) изменения и усовершенствования сетей;

2) использования новых технологий;

3) использования новых продуктов или новых версий/выпусков;

4) использования новых инструментов и сред разработки;

5) изменения физического расположения средств обслуживания;

6) смены поставщиков;

7) заключения контракта с другим субподрядчиком.

      16 Менеджмент инцидентов информационной безопасности

      16.1 Менеджмент инцидентов информационной безопасности и улучшений

Цель: Обеспечить последовательный и эффективный подход к менеджменту инцидентов ИБ, включая обмен информацией о событиях безопасности и недостатках.

16.1.1 Обязанности и процедуры

Мера обеспечения ИБ

Должны быть установлены обязанности и процедуры менеджмента для обеспечения уверенности в быстром, эффективном и надлежащем реагировании на инциденты ИБ.

Руководство по применению

Должны быть приняты во внимание следующие рекомендации для обязанностей и процедур по управлению инцидентами ИБ:

a) должны быть установлены обязанности по управлению, чтобы гарантировать, что следующие процедуры разработаны и должным образом доведены до сведения внутри организации:

1) процедуры планирования и подготовки реагирования на инциденты;

2) процедуры мониторинга, обнаружения, анализа и информирования о событиях и инцидентах безопасности;

3) процедуры регистрации действий по управлению инцидентами;

4) процедуры обращения с криминалистическими свидетельствами;

5) оценка недостатков ИБ;

6) процедуры реагирования, включая процедуры эскалации, контролируемого восстановления после инцидента и информирования персонала внутри организации, лиц за ее пределами, а также организаций;

b) установленные процедуры должны обеспечивать, что:

1) вопросы, связанные с инцидентами ИБ в организации, решает компетентный персонал;

2) существуют контактные лица по вопросам обнаружения и информирования об инцидентах безопасности;

3) поддерживаются соответствующие контакты с органами власти, внешними заинтересованными группами или форумами, которые занимаются вопросами, связанными с инцидентами ИБ;

c) процедуры оповещения должны включать в себя:

1) подготовку форм оповещения о событиях безопасности для обеспечения действий по оповещению и для того, чтобы лица, сообщающие о нарушениях, могли запомнить все необходимые действия в случае, если произошло событие безопасности;

2) процедуру, которая должна быть предпринята в случае, если произошло событие ИБ, например немедленное фиксирование всех деталей, таких как вид несоответствия или нарушения, произошедший отказ, сообщения на экране и незамедлительное оповещение контактных лиц, а также принятие скоординированных действий;

3) ссылку на установленный формальный процесс принятия дисциплинарных мер к работникам, которые совершают нарушения безопасности;

4) соответствующие процессы обратной связи для обеспечения того, чтобы лица, сообщающие о событиях безопасности, были уведомлены о результатах после решения и закрытия проблемы.

Цели управления инцидентами ИБ должны быть согласованы с руководством и должны гарантировать, что лица, ответственные за управление инцидентами ИБ, понимают приоритеты организации при обработке инцидентов ИБ.

Дополнительная информация

Инциденты ИБ могут выходить за пределы организационных и национальных границ. Для реагирования на такие инциденты возрастает необходимость в координации и обмене информацией об этих инцидентах со сторонними организациями, в той мере, насколько это возможно.

Подробное руководство по управлению инцидентами ИБ приведено в ИСО/МЭК 27035 [20].

16.1.2 Сообщения о событиях информационной безопасности

Мера обеспечения ИБ

Требуется незамедлительно сообщать о событиях информационной безопасности по соответствующим каналам управления.

Руководство по применению

Все работники и подрядчики должны быть осведомлены о своей обязанности незамедлительно сообщать о событиях ИБ. Они должны быть также осведомлены о процедуре оповещения о событиях безопасности и контактных лицах, которым следует сообщать о событиях.

Ситуации, которые предполагают передачу сообщения о событии ИБ, включают в себя:

a) неэффективный контроль ИБ;

b) нарушение ожидаемого уровня целостности, конфиденциальности или доступности информации;

c) человеческие ошибки;

d) несоответствия политикам или руководствам;

e) нарушения мер физической безопасности;

f) неконтролируемые системные изменения;

g) неисправности программного или аппаратного обеспечения;

h) нарушения доступа.

Дополнительная информация

Сбои или иное ненормальное поведение системы могут быть индикаторами атак на систему защиты или фактического нарушения защиты, и следовательно о них всегда необходимо сообщать как о событиях ИБ.

16.1.3 Сообщение о недостатках информационной безопасности

Мера обеспечения ИБ

Работники и подрядчики, использующие информационные системы и услуги организации, должны обращать внимание на любые замеченные или предполагаемые недостатки ИБ в системах или сервисах и сообщать о них.

Руководство по применению

Все работники и подрядчики должны незамедлительно сообщать о недостатках ИБ контактных лиц, чтобы предотвратить инциденты ИБ. Механизм оповещения должен быть максимально простым, доступным и работоспособным.

Дополнительная информация

Работникам и подрядчикам должно быть рекомендовано не пытаться проверять предполагаемые недостатки безопасности. Тестирование недостатков может быть воспринято как потенциально неправильное использование системы, а также может повредить информационную систему или сервис и привести к юридической ответственности лица, выполняющего тестирование.

16.1.4 Оценка и принятие решений в отношении событий информационной безопасности

Мера обеспечения ИБ

Должна быть проведена оценка событий безопасности и принято решение, следует ли их классифицировать как инциденты ИБ.

Руководство по применению

Контактные лица по вопросам обнаружения и информирования об инцидентах должны оценивать каждое событие безопасности, используя согласованную шкалу классификации событий и инцидентов безопасности, и решать, следует ли классифицировать событие как инцидент ИБ. Классификация и распределение инцидентов по приоритетам может помочь в определении влияния и масштаба инцидента.

В тех случаях, когда в организации есть группа реагирования на инциденты ИБ (ГРИИБ), оценка и принятие решения могут быть переданы ей для подтверждения или повторной оценки.

Результаты оценки и принятых решений должны быть подробно зафиксированы с целью обращения к ним в будущем и проверки.

16.1.5 Реагирование на инциденты информационной безопасности

Мера обеспечения ИБ

Реагирование на инциденты ИБ должно осуществляться в соответствии с документально оформленными процедурами.

Руководство по применению

Реагирование на инциденты ИБ должно осуществляться назначенными контактными лицами и другими соответствующими лицами из числа самой организации или сторонних организаций (см. 16.1.1).

Реагирование должно включать в себя следующее:

a) как можно более быстрый сбор свидетельств произошедшего;

b) проведение криминалистического анализа ИБ по мере необходимости (см. 16.1.7);

c) эскалация, если требуется;

d) обеспечение того, что все выполняемые действия по реагированию соответствующим образом зарегистрированы для дальнейшего анализа;

e) информирование о факте инцидента ИБ или любых существенных деталях о нем других лиц из числа самой организации или сторонних организаций в соответствии с принципом «необходимого знания»;

f) устранение недостатка(ов) ИБ, которые могут стать причиной или способствовать возникновению инцидента;

g) после того, как инцидент успешно отработан, необходимо формально закрыть и записать его.

После инцидента должен проводиться анализ для выявления первопричины инцидента.

Дополнительная информация

Первоочередной целью реагирования на инцидент является возобновление «нормального уровня безопасности», а затем инициирование необходимого восстановления.

16.1.6 Извлечение уроков из инцидентов информационной безопасности

Мера обеспечения ИБ

Знания, приобретенные в результате анализа и урегулирования инцидентов ИБ, должны использоваться для уменьшения вероятности или влияния будущих инцидентов.

Руководство по применению

Должны быть внедрены механизмы, позволяющие количественно определять и отслеживать типы, объемы и стоимость инцидентов ИБ. Информация, полученная в результате оценки инцидентов ИБ, должна использоваться для выявления повторяющихся или значительных инцидентов.

Дополнительная информация

Оценка инцидентов ИБ может указывать на необходимость в усилении или дополнении мер обеспечения ИБ для снижения частоты, ущерба и стоимости в будущем или может быть принята во внимание при пересмотре политики безопасности (см. 5.1.2).

При должном внимании к аспектам конфиденциальности, истории про реальные инциденты ИБ могут быть использованы при обучении персонала (см. 7.2.2) в качестве примеров того, что может случиться, как реагировать на такие инциденты и как избежать их в будущем.

16.1.7 Сбор свидетельств

Мера обеспечения ИБ

В организации должны быть определены и применяться процедуры для идентификации, сбора, получения и сохранения информации, которая может использоваться в качестве свидетельств.

Руководство по применению

Должны быть разработаны и затем выполняться внутренние процедуры при рассмотрении свидетельств с целью принятия мер дисциплинарного и юридического характера.

В общем случае эти процедуры должны обеспечивать процессы идентификации, сбора, получения и сохранения свидетельств в зависимости от типа носителей, устройств и состояния устройств, например включенных или выключенных. Процедуры должны учитывать:

a) цепочку поставок;

b) безопасность свидетельств;

c) безопасность персонала;

d) роли и обязанности задействованного персонала;

e) компетентность персонала;

f) документацию;

g) инструктаж.

Там, где это возможно, должна быть предусмотрена сертификация или другие соответствующие способы оценки квалификации персонала и инструментария для того, чтобы повысить ценность сохраненных свидетельств.

Криминалистические свидетельства могут выходить за пределы организации или границы юрисдикции. В таких случаях следует обеспечить, чтобы организация имела право собирать требуемую информацию в качестве криминалистических свидетельств. Должны быть учтены требования различных юрисдикции, чтобы максимально увеличить шансы на признание в соответствующих юрисдикциях.

Дополнительная информация

Идентификация — это процесс, включающий в себя поиск, распознавание и документирование возможного свидетельства. Сбор — это процесс сбора физических предметов, которые могут содержать потенциальные свидетельства. Получение — это процесс создания копии данных в рамках определенного набора. Сохранение — это процесс поддержания и защиты целостности и первоначального состояния потенциальных свидетельств.

Когда событие безопасности обнаружено впервые, может быть неясно, приведет ли это событие к судебному разбирательству. Следовательно, существует опасность, что необходимое свидетельство будет намеренно или случайно уничтожено до того, как выяснится серьезность инцидента. Рекомендуется заранее привлекать юриста или полицию к любым предполагаемым действиям юридического характера и прислушиваться к советам по поводу необходимых свидетельств.

ИСО/МЭК 27037 [24] содержит руководства по идентификации, сбору, получению и сохранению цифровых свидетельств.

      17 Аспекты информационной безопасности в рамках менеджмента непрерывности деятельности организации

      17.1 Непрерывность информационной безопасности

Цель: Непрерывность обеспечения ИБ должна быть неотъемлемой частью систем менеджмента непрерывности деятельности организации.

17.1.1 Планирование непрерывности информационной безопасности

Мера обеспечения ИБ

Организация должна определить свои требования к ИБ и менеджменту непрерывности ИБ при неблагоприятных ситуациях, например во время кризиса или бедствия.

Руководство по применению

Организация должна определить, обеспечивается ли непрерывность ИБ в рамках процесса менеджмента непрерывностью бизнеса или в рамках процесса менеджмента восстановления после чрезвычайных ситуаций. Требования ИБ должны быть определены при планировании непрерывности бизнеса и восстановления после чрезвычайных ситуаций. При отсутствии формально утвержденных планов непрерывности бизнеса и восстановления после чрезвычайных ситуаций управление ИБ должно исходить из того, что требования ИБ в неблагоприятных ситуациях те же, что и при обычных условиях. В качестве альтернативы организация может провести анализ влияния на бизнес в разрезе аспектов ИБ, чтобы определить требования ИБ, которые применимы в неблагоприятных ситуациях.

Дополнительная информация

Чтобы сократить время и затраты на дополнительный анализ влияния на бизнес, рекомендуется учитывать аспекты ИБ в рамках обычного анализа влияния на менеджмент непрерывности бизнеса или восстановления после чрезвычайных ситуаций. Это предполагает, что требования к непрерывности ИБ четко сформулированы в процессах менеджмента непрерывности бизнеса или восстановления после чрезвычайных ситуаций. Информацию о менеджменте непрерывности бизнеса можно найти в ИСО 27031 [14], ИСО 22313 [9] и ИСО 22301 [8].

17.1.2 Реализация непрерывности информационной безопасности

Мера обеспечения ИБ

Организация должна установить, документировать, реализовать и поддерживать процессы, процедуры, а также меры для обеспечения требуемого уровня непрерывности ИБ при неблагоприятных ситуациях.

Руководство по применению

Организация должна обеспечить следующее:

a) наличие адекватной структуры управления по подготовке, реагированию и снижению последствий от неблагоприятных событий, включающей персонал, обладающий необходимым опытом, компетенциями и полномочиями;

b) утверждение ответственного персонала по реагированию на инциденты, обладающего необходимыми полномочиями и компетенциями, для управления инцидентами и обеспечения ИБ;

c) разработку и утверждение документированных планов, процедур реагирования и восстановления, подробно описывающих, как организация будет справляться с неблагоприятным событием и будет поддерживать ИБ на заранее определенном уровне, основанном на утвержденных руководством целях обеспечения непрерывности ИБ (см. 17.1.1).

В соответствии с требованиями непрерывности ИБ организация должна установить, задокументировать, реализовать и поддерживать:

a) меры обеспечения ИБ в процессах обеспечения непрерывности бизнеса или восстановления после аварийных ситуаций, процедуры, вспомогательные системы и инструменты;

b) процессы, процедуры и изменения для поддержания существующих мер обеспечения ИБ во время неблагоприятных ситуаций;

c) компенсирующие меры для тех мер обеспечения ИБ, которые не могут поддерживаться во время неблагоприятной ситуации.

Дополнительная информация

В контексте непрерывности бизнеса или восстановления после аварий могут быть определены конкретные процессы и процедуры. Информация, обрабатываемая в рамках этих процессов и процедур или поддерживающих информационных систем, должна быть защищена. Поэтому организация должна привлекать специалистов по ИБ при создании, внедрении и поддержке процессов и процедур обеспечения непрерывности бизнеса или восстановления после аварий.

Внедренные меры обеспечения ИБ должны оставаться работоспособными в неблагоприятных ситуациях. Если меры не могут продолжать выполнять свои функции по защите информации, следует определить, внедрить и поддерживать другие меры для обеспечения приемлемого уровня ИБ.

17.1.3 Проверка, анализ и оценивание непрерывности информационной безопасности

Мера обеспечения ИБ

Организация должна регулярно проверять установленные и реализованные меры по обеспечению непрерывности ИБ, чтобы обеспечить уверенность в их актуальности и эффективности при возникновении неблагоприятных ситуаций.

Руководство по применению

Организационные, технические, процедурные изменения или изменения в процессах как в контексте эксплуатации, так и непрерывности, могут привести к изменениям требований непрерывности ИБ. В таких случаях непрерывность процессов, процедур и мер обеспечения ИБ должна быть проанализирована с точки зрения изменений в требованиях.

Организации должны проверять непрерывность менеджмента ИБ путем:

a) осуществления и тестирования функциональности процессов, процедур и мер непрерывности ИБ для гарантии их соответствия целям обеспечения непрерывности ИБ;

b) осуществления и тестирования осведомленности и порядка управления процессами, процедурами и мерами непрерывности ИБ для гарантии того, что их выполнение соответствует целям обеспечения непрерывности ИБ;

c) анализа пригодности и эффективности мер непрерывности ИБ при изменении информационных систем, процессов, процедур и мер обеспечения ИБ или процессов и решений менеджмента непрерывности бизнеса/восстановления после аварий.

Дополнительная информация

Проверка мер непрерывности ИБ отличается от общей проверки ИБ и должна проводиться вне рамок тестирования изменений. По возможности желательно интегрировать проверку мер непрерывности ИБ в проверку непрерывности бизнеса организации или проверку восстановления после аварийной ситуации.

      17.2 Резервирование оборудования

Цель: Обеспечить уверенность в доступности средств обработки информации.

17.2.1 Доступность средств обработки информации

Мера обеспечения ИБ

Средства обработки информации должны быть внедрены с учетом резервирования, достаточного для выполнения требований доступности.

Руководство по применению

Организации должны определить требования бизнеса к доступности информационных систем. В тех случаях, когда доступность не может быть обеспечена существующей системной архитектурой, следует рассмотреть возможность добавления избыточности компонентам и архитектуре.

Там, где это применимо, обеспечивающие избыточность информационные системы должны быть проверены для гарантии того, что переключение с одного компонента на другой функционирует должным образом.

Дополнительная информация

Внедрение избыточности может порождать риски нарушения целостности или конфиденциальности информации и информационных систем. Их необходимо учитывать при проектировании информационных систем.

      18 Соответствие

      18.1 Соответствие правовым и договорным требованиям

Цель: Избежать нарушений правовых и регулятивных требований или договорных обязательств, связанных с ИБ, и других требований безопасности.

18.1.1 Идентификация применимых законодательных и договорных требований

Мера обеспечения ИБ

Все соответствующие законодательные, нормативные, контрактные требования, а также подход организации к удовлетворению этих требований должны быть явным образом определены, документированы и сохраняться актуальными для каждой информационной системы и организации.

Руководство по применению

Конкретные меры и индивидуальные обязанности по выполнению этих требований также должны быть определены и задокументированы.

Руководство должно определить все законодательные акты, требования которых применимы к бизнесу организации и должны выполняться. Если организация ведет бизнес в нескольких странах, руководство должно учитывать требования каждой страны.

18.1.2 Права на интеллектуальную собственность

Мера обеспечения ИБ

Должны быть реализованы соответствующие процедуры для обеспечения уверенности в соблюдении правовых, регулятивных и договорных требований, связанных с правами на интеллектуальную собственность и правами на использование проприетарных программных продуктов.

Руководство по применению

В отношении любых материалов, которые могут рассматриваться как интеллектуальная собственность, необходимо рассмотреть следующие рекомендации:

a) выпуск политики соблюдения прав на интеллектуальную собственность, которая определяет законное использование программного обеспечения и информационных продуктов;

b) приобретение программного обеспечения только у известных и доверенных источников для гарантии того, что авторское право не нарушается;

c) поддержание осведомленности о политике защиты прав интеллектуальной собственности и уведомление о намерении принять дисциплинарные меры в отношении нарушителей;

d) ведение соответствующих реестров активов и идентификация всех активов с требованиями по защите прав интеллектуальной собственности;

e) сохранение подтверждений и свидетельств прав собственности на лицензии, диски с дистрибутивами, руководства и т.д.;

f) внедрение мер обеспечения ИБ для гарантии того, чтобы не было превышено максимальное количество пользователей, установленное в рамках лицензии;

g) проведение проверок на предмет того, что установлено только авторизованное программное обеспечение и лицензионные продукты;

h) предоставление политики по поддержке соответствующих лицензионных соглашений;

i) предоставление политики по утилизации или передаче программного обеспечения другим лицам;

j) соблюдение условий использования программного обеспечения и информации, полученных из общедоступных сетей;

k) не дублировать, конвертировать и извлекать информацию из коммерческих записей (видео, аудио), если это нарушает законы об авторском праве;

I) не копировать полностью или частично книги, статьи, отчеты и другие документы, кроме разрешенных законом об авторском праве.

Дополнительная информация

Права на интеллектуальную собственность включают в себя авторское право на программное обеспечение или документы, права на проекты, торговые марки, патенты и лицензии на исходный код.

Проприетарные программные продукты обычно поставляются в соответствии с лицензионным соглашением, в котором указывают условия лицензии, например ограничение использования продукта конкретным компьютером или ограничение копирования только созданием резервных копий. Ситуацию в отношении прав на интеллектуальную собственность на программное обеспечение, разработанное организацией, следует разъяснить персоналу.

Законодательные, нормативные и договорные требования могут вводить ограничения на копирование материалов, являющихся предметом собственности. В частности, данные ограничения могут содержать требования на использование только тех материалов, которые разработаны организацией или предоставлены по лицензии, или переданы разработчикам для организации. Нарушение авторского права может привести к судебному иску, который может повлечь за собой штрафы и уголовное преследование.

18.1.3 Защита записей

Мера обеспечения ИБ

Записи должны быть защищены от потери, уничтожения, фальсификации, несанкционированного доступа и разглашения в соответствии с правовыми, регулятивными, договорными и бизнес-требованиями.

Руководство по применению

При принятии решения о защите определенных документов организации следует учитывать то, как они классифицированы по схеме организации. Записи должны быть разделены на типы, например бухгалтерские счета, записи баз данных, журналы транзакций, журналы событий и эксплуатационные процедуры. Для каждого из типов должен быть определен период хранения и допустимый носитель, например бумага, микрофиша, магнитная лента, оптические диски. Все криптографические ключи и программы, имеющие отношение к зашифрованным архивам или цифровым подписям (раздел 10), также должны сохраняться, чтобы обеспечить возможность расшифровывания записей во время их хранения.

Следует учитывать возможность порчи носителей, используемых для хранения записей. Процедуры их хранения и обработки должны осуществляться в соответствии с рекомендациями производителя.

Там, где выбираются электронные носители данных, должны быть установлены процедуры, обеспечивающие возможность доступа к данным (читаемость носителей и формата данных) в течение срока их хранения с целью защиты от потери в результате будущих изменений технологии.

Системы хранения данных следует выбирать таким образом, чтобы требуемые данные могли быть извлечены в приемлемые сроки и в приемлемом формате в зависимости от применимых требований.

Система хранения и обработки должна обеспечивать четкую идентификацию записей, а также период их хранения, установленный соответствующими национальными или региональными законами и нормами. Необходимо, чтобы эта система предоставляла возможность уничтожения документов после того, как у организации отпадет потребность в их хранении.

Для достижения целей защиты записей в организации должны быть предприняты следующие шаги:

a) должны быть выпущены руководящие принципы по срокам, хранению, обработке и утилизации записей и информации;

b) должен быть составлен график хранения с указанием записей и периода времени, в течение которого они должны храниться;

c) следует вести перечень источников ключевой информации.

Дополнительная информация

Может потребоваться обеспечение надежного хранения некоторых записей для соответствия законодательным, нормативным или договорным требованиям, а также для обеспечения основных видов деятельности бизнеса организации. Примерами являются записи, которые могут потребоваться в качестве доказательства того, что организация ведет деятельность в соответствии с законодательными и нормативными документами, для обеспечения защиты от потенциального гражданского или уголовного преследования, или для подтверждения финансового состояния организации акционерам, аудиторам и внешним сторонам. Национальное законодательство или нормативные акты могут устанавливать периоды времени и содержание данных для сохранения.

Дополнительную информацию о менеджменте записей организации можно найти в ИСО 15489-1 [5].

18.1.4 Конфиденциальность и защита персональных данных

Мера обеспечения ИБ

Конфиденциальность и защита персональных данных должна обеспечиваться в соответствии с требованиями соответствующих законодательных и нормативных актов там, где это применимо.

Руководство по применению

Должна быть разработана и внедрена политика организации в отношении конфиденциальности и защиты персональных данных. Эта политика должна быть доведена до сведения всех лиц, участвующих в обработке персональных данных.

Соблюдение этой политики и всех соответствующих законодательных актов и требований регуляторов, касающихся защиты неприкосновенности частной жизни людей и защиты персональных данных, требует подходящей структуры управления и контроля. Зачастую это лучше всего достигается назначением ответственного лица, такого как работника, ответственного за конфиденциальность, который должен предоставлять указания менеджерам, пользователям и поставщикам услуг относительно их индивидуальных обязанностей и конкретных процедур, которые они должны соблюдать. Ответственность за обработку персональных данных и обеспечение осведомленности о принципах конфиденциальности должна рассматриваться в соответствии с применимым законодательством и требованиями регуляторов. Должны быть приняты подходящие технические и организационные меры для защиты персональных данных.

Дополнительная информация

ИСО/МЭК 29100 [25] предоставляет высокоуровневую основу для защиты персональных данных в информационно-коммуникационных системах. Ряд стран ввели законодательство, устанавливающее контроль над сбором, обработкой и передачей персональных данных (как правило, это информация о живых людях, при помощи которой они идентифицируются). В зависимости от соответствующего национального законодательства, меры обеспечения ИБ могут налагать обязанности на тех, кто собирает, обрабатывает и распространяет персональные данные, а также могут ограничивать возможность их передачи в другие страны.

18.1.5 Регулирование криптографических мер обеспечения информационной безопасности

Мера обеспечения ИБ

Криптографические меры обеспечения информационной безопасности должны использоваться с соблюдением требований всех соответствующих соглашений, правовых и регулятивных актов.

Руководство по применению

Для соответствия применимым соглашениям, правовым актам и требованиям регуляторов, следует рассмотреть:

a) ограничения на импорт или экспорт компьютерного оборудования и программного обеспечения, выполняющего криптографические функции;

b) ограничения на импорт или экспорт компьютерного оборудования и программного обеспечения, спроектированного с учетом того, что в них могут быть добавлены криптографические функции;

c) ограничения на использование шифрования;

d) обязательные или добровольные методы доступа государственных органов к информации, зашифрованной с использованием аппаратного или программного обеспечения для обеспечения конфиденциальности информации.

Следует обратиться за юридической консультацией по вопросам соблюдения применимых законодательных и нормативных актов. Прежде, чем зашифрованная информация или криптографическое средство покинет границы юрисдикции, следует также получить юридическую консультацию.

      18.2 Проверки информационной безопасности

Цель: Обеспечить уверенность в том, что ИБ реализована и эксплуатируется в соответствии с политикой и процедурами организации.

18.2.1 Независимая проверка информационной безопасности

Мера обеспечения ИБ

Подход организации к менеджменту ИБ и ее реализация (т.е. цели, меры и средства, политики, процессы и процедуры ИБ) должны проверяться независимо друг от друга через запланированные интервалы времени или в случае значительных изменений.

Руководство по применению

Руководство должно инициировать проведение независимой проверки. Такая независимая проверка необходима для обеспечения постоянной пригодности, адекватности и эффективности подхода организации к управлению ИБ. Проверка должна включать оценку возможностей для улучшения и необходимости изменений в подходе к безопасности, включая задачи политики и мер обеспечения ИБ.

Такая проверка должна выполняться лицами, не связанными с проверяемой областью, например теми, кто проводит внутренние аудиты, независимыми руководителями или сторонними организациями, специализирующимися на проведении таких проверок. Лица, проводящие проверки, должны иметь соответствующие навыки и опыт.

Результаты независимой проверки должны быть задокументированы и доведены до сведения руководства, которое инициировало проверку. Эти записи должны сохраняться.

Если независимая проверка выявляет, что подход организации и реализация управления ИБ недостаточны, например документированные цели и требования не выполняются или не соответствуют направлению ИБ, установленному в политиках ИБ (см. 5.1.1), руководство должно рассмотреть необходимость корректирующих действий.

Дополнительная информация

ИСО/МЭК 27007 [12] «Руководство по аудиту систем управления информационной безопасностью» и ИСО/МЭК ТО 27008 [13] «Руководство для аудиторов по мерам обеспечения информационной безопасности» также предоставляют руководства для проведения независимой проверки.

18.2.2 Соответствие политикам и стандартам безопасности

Мера обеспечения ИБ

Руководители, в пределах своей зоны ответственности, должны регулярно проверять соответствие процессов и процедур обработки информации соответствующим политикам ИБ, стандартам и любым другим требованиям безопасности.

Руководство по применению

Руководство должно определять, каким образом проверять соответствие требованиям ИБ, определенным в политиках, стандартах и других применимых нормативных актах. Необходимо рассмотреть возможность применения инструментов автоматизированного анализа и формирования отчетности для обеспечения эффективных регулярных проверок.

Если в результате проверки обнаружено несоответствие, руководству следует:

a) выявить причины несоответствия;

b) оценить необходимость выполнения действий для обеспечения соответствия;

c) принять соответствующие корректирующие меры;

d) проверить эффективность предпринятых корректирующих действий и выявить любые недостатки или слабости.

Результаты проверок и корректирующих действий, выполненных руководством, должны быть зафиксированы, а эти записи должны быть сохранены. Руководство должно сообщить о результатах лицам, проводящим независимые проверки (см. 18.2.1), когда проводится независимая проверка в области их ответственности.

Дополнительная информация

Применение систем оперативного мониторинга описано в 12.4.

18.2.3 Анализ технического соответствия

Мера обеспечения ИБ

Информационные системы должны регулярно проверяться на предмет соответствия стандартам и политикам ИБ организации.

Руководство по применению

Техническое соответствие должно проверяться предпочтительно с помощью автоматизированных инструментов, которые генерируют технические отчеты для последующей интерпретации техническим специалистом. Кроме этого, опытный системный инженер может проводить ручные проверки (с использованием соответствующих программных средств, при необходимости).

Если используются тесты на проникновение или оценка уязвимостей, следует проявлять осторожность, поскольку такие действия могут привести к нарушению безопасности системы. Такие тесты следует планировать, документировать и повторять.

Любая проверка технического соответствия должна проводиться только компетентными уполномоченными лицами или под их наблюдением.

Дополнительная информация

Проверки технического соответствия включают в себя экспертизу эксплуатируемых систем на предмет того, что аппаратные и программные меры обеспечения ИБ были правильно реализованы. Этот тип проверки соответствия требует наличия специалиста по технической экспертизе.

К проверкам соответствия относятся, например, тестирование на проникновение и оценка уязвимостей, которые могут проводиться независимыми экспертами, привлекаемыми на контрактной основе специально для этой цели. Это может быть полезным при обнаружении уязвимостей в системе и для проверки того, насколько эффективны меры обеспечения ИБ, направленные на предотвращение несанкционированного доступа, возможного вследствие использования этих уязвимостей.

Тесты на проникновение и оценка уязвимостей дают возможность получить мгновенный снимок системы в конкретном состоянии в конкретный момент времени. Снимок ограничен теми частями системы, которые фактически тестируются во время попытки(ок) осуществления проникновения. Тестирование на проникновение и оценка уязвимостей не заменяют оценку рисков.

ИСО/МЭК ТО 27008 [13] содержит конкретные рекомендации, связанные с проверками технического соответствия.

Приложение ДА

(справочное)

 Сведения о соответствии ссылочных международных стандартов национальным стандартам

Таблица ДА.1

Обозначение ссылочного международного стандарта	Степень соответствия	Обозначение и наименование соответствующего национального стандарта
ISO/IEC 27000	—	*
* Соответствующий национальный стандарт отсутствует. До его принятия рекомендуется использовать перевод на русский язык данного международного стандарта. Официальный перевод данного международного стандарта находится в Федеральном информационном фонде стандартов.

 Библиография

[1]	ISO/IEC Directives, Part 2
[2]	ISO/IEC 11770-1, Information technology Security techniques — Key management — Part 1: Framework
[3]	ISO/IEC 11770-2, Information technology — Security techniques — Key management — Part 2: Mechanisms using symmetric techniques
[4]	ISO/IEC 11770-3, Information technology — Security techniques — Key management — Part 3: Mechanisms using asymmetric techniques
[5]	ISO 15489-1, Information and documentation — Records management — Part 1: General
[6]	ISO/IEC 20000-1, Information technology — Service management — Part 1: Service management system requirements
[7]	ISO/IEC 20000-2, Information technology — Service management — Part 2: Guidance on the application of service management systems
[8]	ISO 22301, Societal security — Business continuity management systems — Requirements
[9]	ISO 22313, Societal security — Business continuity management systems — Guidance
[10]	ISO/IEC 27001, Information technology — Security techniques — Information security management systems — Requirements
[11]	ISO/IEC 27005, Information technology — Security techniques — Information security risk management
[12]	ISO/IEC 27007, Information technology — Security techniques — Guidelines for information security management systems auditing
[13]	ISO/IEC TR 27008, Information technology — Security techniques — Guidelines for auditors on information security controls
[14]	ISO/IEC 27031, Information technology — Security techniques — Guidelines for information and communication technology readiness for business continuity
[15]	ISO/IEC 27033-1, Information technology — Security techniques — Network security — Part 1: Overview and concepts
[16]	ISO/IEC 27033-2, Information technology — Security techniques — Network security — Part 2: Guidelines for the design and implementation of network security
[17]	ISO/IEC 27033-3, Information technology — Security techniques — Network security — Part 3: Reference networking scenarios — Threats, design techniques and control issues
[18]	ISO/IEC 27033-4, Information technology — Security techniques — Network security — Part 4: Securing communications between networks using security gateways
[19]	ISO/IEC 27033-5, Information technology — Security techniques — Network security — Part 5: Securing communications across networks using Virtual Private Network (VPNs)
[20]	ISO/IEC 27035, Information technology — Security techniques — Information security incident management
[21]	ISO/IEC 27036-1, Information technology — Security techniques — Information security for supplier relationships — Part 1: Overview and concepts
[22]	ISO/IEC 27036-2, Information technology — Security techniques — Information security for supplier relationships — Part 2: Common requirements
[23]	ISO/IEC 27036-3, Information technology — Security techniques — Information security for supplier relationships — Part 3: Guidelines for ICT supply chain security
[24]	ISO/IEC 27037, Information technology — Security techniques — Guidelines for identification, collection, acquisition and preservation of digital evidence
[25]	ISO/IEC 29100, Information technology — Security techniques — Privacy framework
[26]	ISO/IEC 29101, Information technology — Security techniques — Privacy architecture framework
[27]	ISO 31000, Risk management — Principles and guidelines

УДК 006.34:004.056:004.056.5:004.056.53:006.354	ОКС 35.030
Ключевые слова: информационная безопасность (ИБ), система менеджмента информационной безопасности (СМИБ), менеджмент риска, меры обеспечения ИБ