СОИБ. Анализ. Порядок обеспечения безопасности ИСПДн, ГИС и АСУ

Хочу всех поздравить с тем, что наконец закончилась долгоиграющая разработка методического документа ФСТЭК России по защите ГИС. Он подписан и опубликован. Так-же недавно был выложен на рассмотрение проект требований по защите АСУ, во многом схожий с по порядку выполнения работ и составу мер защиты с приказами № 21 и №17.

На недавней конференции "Актуальные вопросы защиты информации" представители ФСБ России так-же отметили что существенных изменений в проект приказа по защите ПДн они вносить не будут и опубликуют его в ближайшее время.

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

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

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

Для ГИС

Для АСУ

Для ИСПДн

Для обработки ПДн по поручению

Так-же рекомендую использовать общий каталог мер защиты, пример которого выложил Андрей Прозоров

В ходе составления схем вылезла ещё одна ошибка в документах.

Приказ №17

“Требования к системе защиты информации информационной системы включаются в техническое задание на создание информационной системы и (или) техническое задание (частное техническое задание) на создание системы защиты информации информационной системы, разрабатываемые с учетом ГОСТ 34.602, ГОСТ Р 51583 и ГОСТ Р 51624, и должны в том числе содержать:

·        …

·        требования к мерам и средствам защиты информации, применяемым в информационной системе;…”

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

Но тот же Приказ №17 говорит нам:

“15.1. При проектировании системы защиты информации информационной системы:

·        …

·        выбираются меры защиты информации, подлежащие реализации в системе защиты информации информационной системы;…”

Методический документ  по защите:

·        “Выбор мер защиты информации для их реализации в информационной системе осуществляется в ходе проектирования системы защиты информации информационной системы в соответствии с техническим заданием на создание информационной системы и (или) техническим заданием (частным техническим заданием) на создание системы защиты информации информационной системы.”

На этапе проектирования опять выбираются меры? Но разве они не были выбраны на этапе разработки ТЗ?

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

PS: Так-же можно почитать отзыв о недавних документах ФСТЭК от Ригеля

СОИБ. Анализ. Экономическая эффективность IDM

14 февраля послушал довольно интересный совместный вебинар BIS-Expert и Trustverse на тему «Как измерить экономический эффект от внедрения IDM?»

Сделаю небольшое отступление в части терминологии.

Если дословно, то IDM (identity management) – управление идентификацией / идентификаторами. Но для корпоративных нужд под IDM обычно понимается – система централизованного управления учетными записями пользователей в ИС и всем что с ними связано с этими учетными записями: правами доступа в ИС, заявками на доступ, паролями, сертификатами и т.п.

The ABCs of Identity Management:

“Identity management is a term that refers broadly to the administration of individual identities within a system, such as a company, a network or even a country. In enterprise IT, identity management is about establishing and managing the roles and access privileges of individual network users. ID management systems provide IT managers with tools and technologies for controlling user access to critical information within an organization.”

WIKI:

“identity management describes the management of individual principals, their authentication, authorization, and privileges within or across system and enterprise boundaries with the goal of increasing security and productivity while decreasing cost, downtime and repetitive tasks.”

По мере развития identity management аналитическое агентство Gartner выделяло два направления: UAP и IAG.

 “User administration and provisioning (UAP) is a combination of administration and analytics technologies that provide an effective foundation for authentication and authorization in the enterprise. Characterized in this way, user administration is a fundamental part of overall IAM technology strategy and program.

 UAP solutions are main engines of identity administration activities. These tools have some or most of the following functions:

·        Workflow and approval automation

·        Password management

·        Other credential management

·        Role life cycle management

·        User access administration

·        Resource access administration

·        Basic identity analytics”

“Identity and access governance (IAG) is defined as (1) the process of requesting, approving, certifying and auditing access to applications, data and other IT services; and (2) the process of delivering security and business intelligence (BI) on how identities are created, managed and used for access. Software tools and services that provide support for most or all of this process are known as IAG products.”

Но Gartner заметили тенденции по объединению в одних системах этих двух направлений и  в декабре 2013 года выпустили отчет в котором два направления IAG и UAP были объединены в одно направление Identity governance and administration (IGA).

“Identity governance and administration (IGA) is a set of processes to manage identity and access information across systems. It includes management of the identity life cycle that creates, maintains and retires identities as needed, as well as governing the access request process, including approval, certification, risk scoring and segregation of duties (SOD) enforcement. Core functionality includes identity life cycle processes, automated provisioning of accounts among heterogeneous systems, access requests (including self-service) and governance over user access to critical systems via workflows for policy enforcement, as well as for access certification processes. Additional capabilities often included in IGA systems are role management, role and entitlements mining, identity analytics, and reporting.”

Экспертное сообщество высказалось что IDM нового поколения – это IGA. (а значит мы можем считать определение IGA  - определением для IDM в рамках данной статьи)

Теперь вернемся к вебинару.

Для обоснования экономической эффективности докладчик предлагал использовать следующие данные (для 1000 пользователей и 3 крупных ИС):

·        среднее время на согласование заявки на доступ к ИС без IDM составляет 15 минут, с IDM – 5 минут

·        среднее количество согласующих лиц без IDM – 5, с IDM – с учетом динамическая оптимизация маршрутов согласования - сокращение количества согласующих лиц до 3

·        среднее время исполнения заявки на изменение доступа (предоставление или изменение доступа в ИС)  без IDM составляет 20 минут, с IDM – выполняется автоматически,  0 минут

·        среднее время первоначального создания учетных записей и базовых прав доступа для нового пользователя на основе его должности без IDM составляет 3 часа, с IDM – выполняется автоматически, 0 минут   

·        среднее время инвентаризации и контроля изменений прав доступа без IDM составляет 2,5 часа в неделю, с IDM – 1 час

·        среднее время анализа и контроля предоставленных / избыточных / критических прав в рамках ежегодного аудита без IDM – 4 дня, с IDM – 2 дня

По расчетам докладчика при таких условиях, операционные затраты Компании на управление учетными записями и правами сократятся на 4 815 320 рублей за два года.

С моей точки зрения, в данном расчете ещё не учтены следующие данные для сокращения затрат:

·        снижение времени расследования инцидентов

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

·        снижение времени на выпуск или перевыпуск сертификатов пользователей (для IDM интегрированных с УЦ)

·        уменьшение времени на блокирование учетных записей ИАФ.3 / лишения доступа уволенных сотрудников. УПД.1

·        уменьшение рисков, связанных с учетными записями уволенных сотрудников (так как с IDM они блокируются автоматически, без IDM могу какое-то время действовать) УПД.1

·        уменьшение рисков, связанных с избыточными правами пользователей (с IDM легче и эффективнее отслеживать избыточные права пользователей, связанные с окончанием проекта, переводом на другую должность и другими временными правами и временными учетными записями)  УПД.4 УПД.5

С учетом приведенных замечаний получается полезный калькулятор расчета ROI для обоснования необходимости внедрения IDM

СОИБ. Анализ. Добавления к каталогу мер защиты от ФСТЭК

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

Документ разработан на основе приказа 17 ФСТЭК Р, на него похож и на столько же хорош.

Порадовал он нас и новыми мерами в каталоге базовых набор мер:

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

Условное обозначение и номер меры	Меры защиты информации в автоматизированных системах управления	Классы защищенности
		3	2	1
VI. Антивирусная защита (АВЗ)
АВЗ.0	Разработка правил и процедур (политик) антивирусной защиты	+	+	+

2.      Добавились новые группы мер по обновлению ПО, планированию ИБ, действиях в непредвиденных ситуациях, обучению пользователей и анализу угроз

Условное обозначение и номер меры	Меры защиты информации в автоматизированных системах управления	Классы защищенности
		3	2	1
XV. Управление обновлениями программного обеспечения (ОПО)
ОПО.0	Разработка правил и процедур (политик) управления обновлениями программного обеспечения (включая получения, проверку и установку обновлений)	+	+	+
ОПО.1	Получение обновлений программного обеспечения от разработчика или уполномоченного им лица	+	+	+
ОПО.2	Тестирование обновлений программного обеспечения до его установки на макете или в тестовой зоне	+	+	+
ОПО.3	Централизованная установка обновлений программного обеспечения
XVI. Планирование мероприятий по обеспечению защиты информации (ПЛН)
ПЛН.0	Разработка правил и процедур (политик) планирования мероприятий по обеспечению защиты информации	+	+	+
ПЛН.1	Определение лиц, ответственных за планирование и контроль мероприятий по обеспечению защиты информации в автоматизированной системе управления	+	+	+
ПЛН.2	Разработка, утверждение и актуализация (обновление) плана мероприятий по обеспечению защиты информации в автоматизированных системах управления	+	+	+
ПЛН.3	Контроль выполнения мероприятий по обеспечению защиты информации в автоматизированных системах управления, предусмотренных утвержденным планом	+	+	+
XVII. Обеспечение действий в нештатных (непредвиденных) ситуациях (ДНС)
ДНС.0	Разработка правил и процедур (политик) обеспечения действий в нештатных (непредвиденных) ситуациях
ДНС.1	Разработка плана действий в случае возникновения нештатных (непредвиденных) ситуаций	+	+	+
ДНС.2	Обучение и отработка действий пользователей в случае возникновения нештатных (непредвиденных) ситуаций	+	+	+
ДНС.3	Создание альтернативных мест хранения и обработки информации в случае возникновения нештатных (непредвиденных) ситуаций	+	+	+
ДНС.4	Резервирование программного обеспечения, технических средств, каналов передачи данных автоматизированных систем управления в случае возникновения нештатных (непредвиденных) ситуаций	+	+	+
ДНС.5	Обеспечение возможности восстановления автоматизированных систем управления и (или) ее компонент в случае возникновения нештатных (непредвиденных) ситуаций
XVIII. Информирование и обучение пользователей (ИПО)
ИПО.0	Разработка правил и процедур (политик) информирования и обучения пользователей	+	+	+
ИПО.1	Информирование пользователей об угрозах безопасности информации, о правилах эксплуатации	+	+	+
ИПО.0	Разработка правил и процедур (политик) информирования и обучения пользователей	+	+	+
ИПО.3	Проведение практических занятий с пользователями по эксплуатации системы защиты автоматизированной системы управления и отдельных средств защиты информации
XIX.Анализ угроз безопасности информации и рисков от их реализации (УБИ)
УБИ.0	Разработка правил и процедур (политик) анализа угроз безопасности информации и рисков от их реализации	+	+	+
УБИ.1	Периодический анализ изменения угроз безопасности информации, возникающих в ходе эксплуатации автоматизированной системы управления	+	+	+
УБИ.2	Периодическая переоценка последствий от реализации угроз безопасности информации (оценка риска)	+	+	+

3.      Так-же добавились группы мер ИНЦ и УКФ по управлению инцидентами и конфигурацией, которые уже встречались в приказе 21 но отсутствовали в приказе 17 ФСТЭК Р.

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

В будущем при обновлении приказов 17 и 21 можно ожидать включение в них этих новых групп мер. Но уже сейчас при разработке СЗПДн или подсистемы ИБ ГИС можно использовать эти новые наборы мер. Зачем придумывать свои варианты, если есть готовый и публично доступный документ – это хоть немного да улучшит взаимопонимание между различными лицами в сфере ИБ.

PS: Если говорить о самом новом проекте Требований по защите АСУ, то явно к его разработке приложили лапу проектные организации по АСУ. Доказательство:

Приказ 17

“4. Настоящие Требования предназначены для обладателей информации, заказчиков, заключивших государственный контракт на создание государственной информационной системы (далее – заказчики) и операторов государственных информационных систем (далее – операторы).

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

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

проект Требования по защите АСУ

“ 4. Настоящие Требования предназначены для лиц, обеспечивающих задание требований к защите информации в автоматизированных системах управления (далее – заказчик), лиц, обеспечивающих эксплуатацию автоматизированных систем управления (далее – оператор), а также лиц, привлекаемых в соответствии с законодательством Российской Федерации к проведению работ по созданию (проектированию) автоматизированных систем управления и (или) их систем защиты (далее – разработчик (проектировщик)).

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

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

Далее произошла трансформация следующего пункта приказа 17:

“15. Разработка системы защиты информации информационной системы организуется обладателем информации (заказчиком).

16. Внедрение системы защиты информации информационной системы организуется обладателем информации (заказчиком).”

в пункт Требований по защите АСУ

“15. Разработка системы защиты автоматизированной системы управления организуется заказчиком и осуществляется разработчиком (проектировщиком) и (или) оператором.

16. Внедрение системы защиты автоматизированной системы управления организуется заказчиком и осуществляется разработчиком (проектировщиком) и (или) оператором.”

Как видно заказчик не может привлекать других лиц к разработке и внедрению системы защиты кроме “проектировщика” и оператора. Налицо желание проектных организаций АСУ захватить в свои руки все работы  – в том числе внедрение СЗИ, разработку организационных мер по ИБ (а там ИСО 27000) и анализ уязвимостей (пентесты).

Я думаю что такое ограничение конкуренции не пойдет на руку Заказчику и преследует интересы узкой группы лиц.