понедельник, 17 августа 2015 г.

СОИБ. Анализ. Уязвимости сертифицированных СЗИ

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

И уже в августе ФСТЭК России начал принимать действия в этом направлении - Заявители отправляющие на сертификацию решения одного (а может и не одного) известного западного вендора получили письмо с предупреждением.  Для западных производителей СЗИ в случае сертификации на экземпляр или партию, Заявитель – это как правило конечный пользователь или интегратор; при сертификации на серию – заявитель как правило партнер в России по сертифицированному производству.

В письме регулятор напоминает, что в сертифицированном СЗИ имеются уязвимости, опубликованные в БДУ высокого и критического уровней опасности. Так-же ФСТЭК России напоминает что Заявители на сертификацию должны обеспечивать соответствие средств защиты информации требованиям безопасности информации (пункт 7 Постановления Правительства РФ от 26 июня 1995 г. N 608 "О сертификации средств защиты информации"), а также принимать меры по обеспечению стабильности характеристик сертифицируемых СЗИ (пункт 2.6 Положения о сертификации средств защиты информации по требованиям безопасности информации Утверждено приказом председателя государственной технической комиссии при Президенте Российской Федерации от 27 октября 1995 г. № 199), в том числе должны принимать меры по выявлению и устранению уязвимостей в производимых или поставляемых СЗИ.

Далее идет просьба проинформировать ФСТЭК о принятых и планируемых мерах по устранению уязвимостей. Исходя из общения с регулятором у меня сложилось впечатление, что варианты по устранению могут быть следующие:
1.       Следуя рекомендациям производителя подобрать версию ПО, в которой все опубликованные уязвимости будут устранены, которая будет работать на имеющейся аппаратной части; провести в системе сертификации ФСТЭК инспекционный контроль новой версии ПО; обновить или уведомить заказчиков о необходимости обновления ПО на всем оборудовании (усложняется в некоторых случаях отсутствием у Заказчика действующего сервиса технической поддержки и соответственно возможности обновить ПО)
2.       Принять организационные меры. В случае если уязвимость связана с определенными сервисами (например, SSL, SIP, управление через web), можно выпустить требования, ограничивающие использование данных сервисов.
3.       Исключить из эксплуатации СЗИ с уязвимостями или уведомить Заказчика о необходимости исключения из эксплуатации СЗИ с уязвимостями


В последнем варианте возможен отзыв сертификата на следующем основании
Постановление Правительства РФ от 26 июня 1995 г. N 608:
“10. Федеральный орган по сертификации и органы по сертификации средств защиты информации имеют право приостанавливать или аннулировать действие сертификата в следующих случаях:
·                    изменение нормативных и методических документов по защите информации в части требований к средствам защиты информации, методам испытаний и контроля;
·                    изменение технологии изготовления, конструкции (состава), комплектности средств защиты информации и системы контроля их качества;
·                    отказ изготовителя обеспечить беспрепятственное выполнение своих полномочий лицами, осуществляющими государственные контроль и надзор, инспекционный контроль за сертификацией и сертифицированными средствами защиты информации.”

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



среда, 5 августа 2015 г.

СОИБ. Анализ. Структура политик по ИБ

В одной из предыдущих статей я делал обзор лучших практик по ИБ (публичный комплекс требований, рекомендаций и стандартов) из Австралии. В них немалое внимание уделяется внутренней документации по ИБ в организации. На этой теме и остановимся подробнее.

В соответствии со стандартом Information Security Manual 2015 - Principles  необходимо сформировать в организации структуру документов по управления информационной безопасностью (Information Security Management Framework), которая должна включать:
·         Политику ИБ (Information security policy, ISP).
·         План управления рисками ИБ (Security risk management plan, SRMP).
·         План системы защиты (System security plan, SSP).
·         Описание стандартных операционных процедур (Standard operating procedures, SOP).
·         План реагирования на инциденты (Incident response plan, IRP).
·         Описание порядка действий в чрезвычайных ситуациях (Emergency procedures, EP)
·         План обеспечения непрерывности и восстановления (Business continuity and disaster recovery plans, BCDRP)

Политика ИБ (ISP) должна затрагивать такие темы как:
·         процедуры оценки соответствия и приемки систем (accreditation processes)
·         ответственность сотрудников (personnel responsibilities)
·         управление конфигурациями (configuration control)
·         управление доступом (access control)
·         безопасное взаимодействие между сетями и системами (networking and connections with other systems)
·         физическая безопасность и управление носителями информации (physical security and media control)
·         процедуры реагирования в чрезвычайных ситуациях и при обнаружении инцидентов ИБ (emergency procedures and cyber security incident management)
·         управление изменениями (change management)
·         повышение осведомленности и обучение по вопросам ИБ (information security awareness and training)

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

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

Требования к описанию стандартных операционных процедур (SOP):
·         должны разрабатываться описания процедур обеспечения ИБ для следующих ролей:
o   менеджер ИБ (Information Technology Security Manager)
o   ответственный за обеспечение ИБ (Information Technology Security Officer)
o   администратор ИТ/ИС (system administrator)
o   пользователь (user)
·         для менеджера по ИБ должны быть описаны как минимум следующие процедуры:
o   (Cyber security incidents) управление и отчетность об инцидентах ИБ


·         для ответственного за обеспечение ИБ должны быть описаны как минимум следующие процедуры:
o   (Access control) управление доступом - авторизация
o   (User account management) управление учетными записями пользователей - авторизация
o   (Asset musters) инвентаризация, учет и управление ИТ активами, включая носители информации
o   (Audit logs) просмотр и анализ логов и записей аудита
o   (Configuration control) контроль и утверждение изменений в составе ПО или конфигурациях
o   (Cyber security incidents) обнаружение инцидентов ИБ, определение причин инцидентов, определение действий, необходимых для устранения или минимизации последствий инцидентов ИБ
o   (Data transfers) проверка отправляемых из организации носителей информации, проверка входящих в организацию носителей информации
o   (ICT equipment) вывод из эксплуатации оборудования и носителей информации
o   (System integrity audit) анализ защищенности ИС, в том числе анализ учетных записей, прав доступа, целостности ПО и данных, тестирование защитных механизмов, проверка оборудования
o   (System maintenance) обеспечение ИБ при эксплуатации систем, в том числе отслеживание уязвимостей ПО, тестирование и применение обновлений, применение дополнительных мер по защите


·         для администратора ИТ/ИС должны быть описаны как минимум следующие процедуры:
o   (Access control) управление доступом - предоставление
o   (User account management) управление учетными записями пользователей - создание, назначение прав, изменение
o   (Configuration control) внесение изменений в составе ПО или конфигурациях
o   (System backup and recovery) резервное копирование и восстановление


·         для пользователя должны быть описаны как минимум следующие процедуры:
o   (Cyber security incidents) действий при подозрении на инцидент ИБ
o   (End of day) действия по безопасному завершению рабочего дня
o   (Media control) работа с носителями информации
o   (Passphrases) создание и использование паролей
o   (Temporary absence) обеспечение безопасности систем при временном отсутствии


·         сотрудники всех озвученных ролей должны быть ознакомлены под роспись с процедурами по ИБ и последствиями их нарушения
Требования к Плану реагирования на инциденты (IRP):
·         должен (must) включаться в IRP как минимум:
o   общее описание инцидентов ИБ
o   минимальные инструкции по реагированию и расследованию инцидентов ИБ
o   группа, ответственная за расследование инцидентов ИБ
o   действия, необходимые для сбора и сохранения свидетельств и доказательств
o   действия, необходимые для непрерывности работы критических ИС
o   форма отчета об инциденте ИБ
·         необходимо (should) включать в IRP:
o   описания типов инцидентов ИБ, которые могут встретится
o   планируемые действия при обнаружении каждого типа инцидентов ИБ
o   критерии, по которым принимается решение о привлечении правоохранительных органов
o   другие лица, которые должны быть проинформированы о начале расследования

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

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

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


Что меня наиболее удивило и в чем сильная сторона структуры документов по Australian ISM – большее внимание уделяется не политике ИБ и подполитикам, а планам и процедурам в области ИБ.