Требования к защите информации и программ в тз

Содержание

Для АС Кадры определены следующие режимы функционирования:

Нормальный режим функционирования;
Аварийный режим функционирования.

Основным режимом функционирования АС является нормальный режим.

Источник — документация заказчика (положение об агентстве)

В нормальном режиме функционирования системы:

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

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

Требования к защите персональных данных в информационных системах

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

В случае перехода системы в аварийный режим необходимо:

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

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

18.4.1.1.5. Требования по диагностированию системы

АС Кадры должна предоставлять инструменты диагностирования основных процессов системы, трассировки и мониторинга процесса выполнения программы.

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

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

Источник — опыт, документация на системы диагностики, ITIL, MOF

18.4.1.1.6. Перспективы развития, модернизации системы

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

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

Источник — документация заказчика (стратегия развития)

18.4.1.2. Требования к численности и квалификации персонала системы

Для эксплуатации АС Кадры определены следующие роли:

не ХАЦКЕР, а Специалист по Информационной Безопасности! | UnderMind

Системный администратор;
Администратор баз данных ;
Администратор информационной безопасности;
Пользователь.

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

Основными обязанностями системного администратора являются:

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

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

Основными обязанностями администратора баз данных являются:

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

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

Основными обязанностями администратора информационной безопасности являются:

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

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

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

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

Рекомендуемая численность для эксплуатации АС Кадры:

Администратор — 1 штатная единица;
Пользователь — число штатных единиц определяется структурой предприятия.

18.4.1.3. Показатели назначения

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

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

для операций навигации по экранным формам системы — не более 5 сек;
для операций формирования справок и выписок — не более 10 сек.

Время формирования аналитических отчетов определяется их сложностью и может занимать продолжительное время.

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

Источник — ОФМ, IDEF3, регламенты (анкеты) пользователей

18.4.1.4. Требования к надежности

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

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

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

Источник — опыт эксплуатации ИС

18.4.1.5. Требования к безопасности

Все внешние элементы технических средств системы, находящиеся под напряжением, должны иметь защиту от случайного прикосновения, а сами технические средства иметь зануление или защитное заземление в соответствии с ГОСТ 12.1.030-81 и ПУЭ.

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

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

Факторы, оказывающие вредные воздействия на здоровье со стороны всех элементов системы (в том числе инфракрасное, ультрафиолетовое, рентгеновское и электромагнитное излучения, вибрация, шум, электростатические поля, ультразвук строчной частоты и т.д.), не должны превышать действующих норм (СанПиН 2.2.2./2.4.1340-03 от 03.06.2003 г.).

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

18.4.1.6. Требования к эргономике и технической эстетике

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

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

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

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

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

Источник — опыт, эргономика, инженерная психология

18.4.1.7. Требования к эксплуатации, техническому обслуживанию, ремонту и хранению компонентов системы

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

18.4.1.8. Требования к защите информации от несанкционированного доступа

ИС должна обеспечивать защиту от несанкционированного доступа (НСД) на уровне не ниже установленного требованиями, предъявляемыми к категории 1Д по классификации действующего руководящего документа Гостехкомиссии России «Автоматизированные системы. Защита от несанкционированного доступа к информации. Классификация автоматизированных систем» 1992 г.

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

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

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

Уровень защищённости от несанкционированного доступа средств вычислительной техники, обрабатывающих конфиденциальную информацию, должен соответствовать требованиям к классу защищённости 6 согласно требованиям действующего руководящего документа Гостехкомиссии России «Средства вычислительной техники. Защита от несанкционированного доступа к информации. Показатели защищенности от несанкционированного доступа к информации».

Защищённая часть системы должна использовать «слепые» пароли (при наборе пароля его символы не показываются на экране либо заменяются одним типом символов; количество символов не соответствует длине пароля).

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

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

Источник — опыт, ведомственные документы заказчика

18.4.1.9. Требования по сохранности информации при авариях

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

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

18.4.1.10. Требования к защите от влияния внешних воздействий

18.4.1.11. Требования к патентной чистоте

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

18.4.1.12. Требования по стандартизации и унификации

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

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

Источник: intuit.ru

Тендер по защите информации. Как подготовить техническое задание

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

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

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

При подготовке ТЗ для тендера желательно руководствоваться требованиями стандарта ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы». Документ поможет выстроить четкую структуру технического задания, определить разделы, которые будут заполняться необходимыми требованиями.

Рассмотрим, на что нужно обратить внимание при заполнении документа.

Техническое задание на тендер, образец (примерная структура)

Общие сведения

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

Основание проведения работ. Цели создания системы

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

Зачастую основанием для создания системы выступают требования законодательства. В таком случае необходимо перечислить нормативные документы, в соответствии с которыми система должна быть создана. Например, требования 152-ФЗ «О персональных данных».

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

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

Общая характеристика информационных систем

Этот раздел посвящен описанию существующей инфраструктуры заказчика. Лучше заполнить этот раздел максимально подробно.

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

Подробное и качественное заполнение данного раздела позволит исполнителю сформировать оптимальное техническое решение.

Требования к системе защиты информации

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

Общие требования к системе

В подразделе «Общие требования к системе» указывают:

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

Требования к функциям, выполняемым системой

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

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

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

Требования к программным средствам

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

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

Требования к техническим средствам

В подразделе указываются:

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

Как писать техстандарт по защите информации для крупной компании

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

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

Первая задача — разобраться, что нужно защищать и как. Чтобы каждый руководитель как «отче наш» знал, какие конкретно меры защиты в отношении каких активов нужно принимать. Важно то, что набор применяемых мер защиты должен быть необходимым и достаточным. То есть безопасно и при этом в бюджете.

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

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

Проблематика, что взято за основу, и что получилось по мерам защиты

Что было в самом начале, или какая была проблематика:

Компания хотела реализовывать меры защиты по какому-то одному «источнику правды». Грубо говоря, нужна была единая на весь холдинг таблица с перечнем того, что нужно сделать, чтобы и ИБ обеспечить, и соответствовать всем необходимым требованиям, спускаемым от регуляторов. И чтобы не было ситуаций, что каждая дочка реализует ИБ как ей вздумается, идя порой вразрез с позицией головы.
Экономия расходов и дифференцированный подход к выбору мер защиты — понятная и единая оценка критичности того, что нужно защищать. Сервер с рецептами в столовой, например, достаточно снабдить антивирусом и убедиться, что он не торчит в большой Интернет по RDP (я утрирую). А вот финансовый сегмент или базы данных HR нужно защищать куда сильнее. А к сегменту АСУ ТП нужен особый подход. Очень часто в компаниях руководители не могли точно оценить, что и в какой степени надо защищать, и защищали активы по принципу «всё на всё», т. е. ставим всё, что сказала головная компания, на все информационные системы вне зависимости от того, есть там ценные данные или их нет.
Компании в холдинге не всегда обеспечивали нужные меры ИБ. Возможность проверить — это возможность заставить всех их обеспечивать.
Естественно, очень хотелось сократить расходы. Как я говорил, это крупные моновендорные закупки и возможность поддерживать меньшее количество разных типов средств защиты.
Ещё одна особенность — безопасников очень бесит видеть, как кто-то выкатывает готовое решение, где не были учтены их требования. Дальше несколько отделов вместе придумывают, что же с этим делать. И за серьёзные деньги и время решают. Новый Технический стандарт ИБ позволял сразу выставить требования к проектированию системы ИБ и передать их как части ТЗ всем дочерним компаниям.

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

К тому же не все меры защиты из NIST применимы и необходимы (зачем реализовывать то, в чём нет необходимости, мы же не хотим нецелевого использования финансовых средств). Также сложности добавляло то, что компания у нас большая, в холдинге есть и промышленные предприятия, и базы отдыха, и гостиницы, и учётные и сервисные компании. Соответственно имеют место быть и персональные данные, и коммерческая тайна, и объекты КИИ, и АСУ ТП.

Что же мы сделали? Сначала мы сделали свободный перевод указанных выше NIST, убрав оттуда меры, в реализации которых нет необходимости. Это, например, меры, направленные на обеспечение ИБ в технологиях, которые неприменимы в нашем холдинге, или меры, в реализации которых нет необходимости согласно утверждённой в холдинге Матрице рисков и угроз (её тоже мы разрабатывали и, возможно, об этом напишем когда-нибудь пост). Затем мы замапили меры защиты из российских нормативных документов с мерами из NIST. Какие-то меры (по понятным причинам) идеально легли в меры из NIST, какие-то не ложились, и приходилось расширять состав мер. Добавились меры из следующих документов:

Федеральный закон от 26.07.2017 № 187-ФЗ «О безопасности критической информационной инфраструктуры Российской Федерации»;
Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных»;
Федеральный закон от 29.07.2004 № 98-ФЗ «О коммерческой тайне»;
Постановление Правительства Российской Федерации от 08.02.2018 № 127 «Об утверждении Правил категорирования объектов критической информационной инфраструктуры Российской Федерации, а также перечня показателей критериев значимости объектов критической информационной инфраструктуры Российской Федерации и их значений»;
Постановление Правительства Российской Федерации от 01.11.2012 № 1119 «Об утверждении требований к защите персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК России от 18.02.2013 № 21 «Об утверждении Состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных»;
Приказ ФСТЭК России от 25.12.2017 № 239 «Об утверждении требований по обеспечению безопасности значимых объектов критической информационной инфраструктуры Российской Федерации»;
Приказ ФСТЭК России от 21.12.2017 № 235 «Об утверждении Требований к созданию систем безопасности значимых объектов критической информационной инфраструктуры Российской Федерации и обеспечению их функционирования»;
Приказ ФСТЭК России от 14.03.2014 № 31 «Об утверждении Требований к обеспечению защиты информации в автоматизированных системах управления производственными и технологическими процессами на критически важных объектах, потенциально опасных объектах, а также объектах, представляющих повышенную опасность для жизни и здоровья людей и для окружающей природной среды». Здесь важный момент в том, что требования приказа носят рекомендательный характер, т. е. если кто-то не выполнит этих требований — проверка не придёт и никого не накажут. Но многие компании применяют эти требования. Почему? Потому что, если АСУ ТП не является объектом КИИ, то с точки зрения закона её можно никак не защищать, а с точки зрения бизнеса в случае реализации угроз в отношении этой АСУ ТП возможен прямой или косвенный ущерб. Ущерб в бизнесе не любят, и почему надо защищать такие АСУ ТП, понимают.

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

Ниже — картинка с подробным описанием конкретной меры:

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

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

Итак, какие же меры вошли в эту таблицу? Есть пять функциональных направлений:

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

Функциональное направление ИБ

Наименование категории

Обозначение категории

Стратегия управления рисками

Осведомлённость и обучение

Процессы и процедуры защиты информации

Аномалии и события

Непрерывный мониторинг безопасности

Планы по реагированию

Планы по восстановлению

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

Процесс выбора мер защиты

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

Пройдёмся по каждому шагу.

Определение типов ИС и АСУ ТП

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

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

В результате определения типов ИС и АСУ ТП формировалась таблица по примеру ниже:

Выбор мер защиты

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

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

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

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

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

Определение профиля для каждой меры защиты

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

Формирование итогового набора мер защиты

Таким образом, по результатам прохождения всего алгоритма выбора мер защиты формируется единый необходимый к выполнению перечень мер защиты, который впоследствии может быть включен в ТЗ на создание/модернизацию ИС/АСУ ТП (или их систем защиты). Пример документирования — ниже:

Процесс выбора средств защиты

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

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

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

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

Результат работы по стандарту

Итак, что же получаем? А получаем, что у нас есть единый «источник правды», по которому любая компания холдинга может выбирать необходимые к реализации меры защиты с учётом специфики своих информационных систем (АСУ ТП) и ИТ-инфраструктуры. Более того, выбрав меры, компания сможет понять, какими средствами защиты эти меры реализовывать. При этом компания может сэкономить на закупке средств защиты, так как понимает, на каких площадках какие компоненты централизованных средств защиты развёрнуты (т. е. понимает, к каким компонентам можно просто подключиться, не тратя денег на их покупку).
Что же касается безопасников, то у них тоже жизнь упростилась. Во-первых, все теперь должны реализовывать требования Технического стандарта (в т. ч. при создании новых систем). Во-вторых, проще проводить проверки, когда определены меры защиты.

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

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

Зная это, представитель ИБ берёт, смотрит, какие системы есть (например, есть ИСПДн с уровнем защищённости 4 и КТ), выбирает необходимые меры защиты, адаптирует и дополняет их (зная актуальные угрозы). Получает конечный набор мер защиты. Далее смотрит ещё в одну таблицу и получает набор средств защиты, необходимых к внедрению на его площадке. Вот и всё.

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

Вместо заключения

Для любителей чисел: в стандарте вышло 30 страниц основной части с описанием подхода и алгоритма работы, и более 100 страниц приложений — с детальным описанием мер защиты, различными выборками, шаблонами отчётных форм.

Сами мы получившийся стандарт апробировали на ряде площадок.

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

Думаю, у вас тоже есть похожая документация. Многие стандартизуют только конкретные решения по ИБ без каких-либо методик по выбору таких решений. Некоторые стандартизуют конкретные меры (преимущественно на базе подходов ФСТЭК России или ЦБ РФ).

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

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

Источник: habr.com