Совокупность последних положений регуляторов предполагает построение замкнутого и адаптивного комплекса требований, создающего предпосылки для построения систем со "встроенной безопасностью", что является необходимым условием обеспечения ИБ современных информационных систем.
2. ЗАО «ПМ» - о нас
О ЗАО «ПМ»
Аналитический и
инструментальный анализ
ПО и ИС
С 2012 года – работаем по
направлению повышения
безопасности разработки
В 2014 запустили ЦМ
Принимаем участие в работе с
регуляторами ИБ – ТК26, ТК362
3. ИБ КВО – вызовы новой эпохи
Априорная безопасность
Вероятностная безопасность
Безопасность по построению
Глобальная проблема
«революционного» развития:
Потребности и сценарии
«на острие прогресса»,
при этом ИБ отстает на годы
http://www.dlg.org/f
7. Основания для безопасности
Требования по обеспечению ЗИ – 31 п. ФСТЭК
Разработка (СЗИ) - ФСТЭК
Безопасная разработка (СЗИ)
Сертификация СЗИ
Эксплуатация - уязвимости (СЗИ) - ФСТЭК
База уязвимостей и процесс их устранения
Мониторинг ИБ – СОПКА ФСБ
8. Пункт 13.3 приказа ФСТЭК России от 14 февраля 2014 г. № 31
«Угрозы безопасности информации определяются на каждом из уровней автоматизированной
системы управления по результатам: анализа возможных уязвимостей
автоматизированной системы управления».
Пункт 15.7 приказа ФСТЭК России от 14 февраля 2014 г. № 31
«По решению заказчика для подтверждения выявленных уязвимостей может проводиться
тестирование автоматизированной системы управления на проникновение.
Указанное тестирование проводится, как правило, на макете (в тестовой зоне)
автоматизированной системы управления.
В случае выявления уязвимостей в автоматизированной системе управления, приводящих к
возникновению дополнительных угроз безопасности информации, проводится
уточнение модели угроз безопасности информациии при необходимости
принимаются дополнительные меры защиты информации, направленные на устранение
выявленных уязвимостей или исключающие возможность эксплуатации нарушителем
выявленных уязвимостей»
Приказ ФСТЭК России № 31 от 14 марта 2014 «Об утверждении Требований к
обеспечению защиты информации в автоматизированных системах управления производственными
и технологическими процессами на критически важных объектах, потенциально опасных объектах, а
также объектах, представляющих повышенную опасность для жизни и здоровья людей и для
окружающей природной среды»
9. ГосСОПКА: нормативная база
Указ Президента Российской Федерации от 15 января 2013 г.
№31с «О создании государственной системы обнаружения,
предупреждения и ликвидации последствий компьютерных
атак на информационные ресурсы Российской Федерации»
http://www.rg.ru/2013/01/18/komp-ataki-site-dok.html
Концепция государственной системы обнаружения,
предупреждения и ликвидации последствий компьютерных
атак на информационные ресурсы Российской Федерации,
утверждённая Президентом Российской Федерации 12
декабря 2014 г. (№ К 1274, далее – Концепция и система
ГосСОПКА соответственно)
http://www.scrf.gov.ru/documents/6/131.html
10. СОПКА: О чём и для чего?
(простыми словами)
Указ определяет:
основные задачи системы ГосСОПКА
ФСБ России – полномочным ведомством по её созданию
дополнительные полномочия ФСБ России в части создания системы
ГосСОПКА
Концепция определяет и детализирует:
назначение, функции и принципы создания системы ГосСОПКА а
также виды обеспечения, необходимые для этого
организационные основы системы ГосСОПКА
нормативно-правовое, научно-техническое, информационно-
аналитическое, кадровое и организационно-штатное обеспечение
создания и функционирования системы ГосСОПКА
Центры мониторинга - основная организационно-технической
составляющая системы ГосСОПКА
12. СОПКА и Центры Мониторинга
Идея создания центров мониторинга имеет не только директивный характер, но
и является результатом эволюции понимания того, как должна выглядеть
система защиты, адекватная актуальным угрозам информационной
безопасности
В соответствии с Концепцией Центры мониторинга являются ядром
ГосСОПКА, без создания и развёртывания которых указанная система не
состоится
Создание ЦМ и ГосСОПКА в целом предполагает активное участие
предприятий промышленности, работающих в области ИБ (лицензиаты ФСБ
России)
Основная техническая задача: обеспечение взаимоувязанной работы СЗИ
различного назначения и создание единой консоли анализа и управления для
них, как ключевого элемента центра мониторинга
Центры Мониторинга
• Территориальные
• Ведомственные
• Корпоративные ЦМ
• Коммерческие ЦМ
(лицензиаты,
сертифицированные СЗИ)
13. Основные задачи Центров мониторинга
Обнаружение, предупреждение и ликвидация последствий
компьютерных атак, направленных на контролируемые
информационные ресурсы
Проведение мероприятий по оценке защищенности
контролируемых информационных ресурсов
Проведение мероприятий по установлению причин
компьютерных инцидентов, вызванных компьютерными
атаками на контролируемые информационные ресурсы
Сбор и анализ данных о состоянии информационной
безопасности в контролируемых информационных ресурсах
Осуществление взаимодействия между Центрами
Информирование заинтересованных лиц и субъектов Системы
по вопросам обнаружения, предупреждения и ликвидации
последствий компьютерных атак
15. «Воронка» обработки информации*
События ИС 106-107
События сенсоров ИБ
500 000
Важные ИБ-
события
150 000
ИБ-
критичные
1000
<<10
* Дневная статистика для организации ~500РС, 50 Серв
Инциденты
19. Безопасная разработка: ГОСТ SDL
Обоснование для
включения в проекты
доп. работ по безопасной
разработке
«Инструкция» по
выполнению требований
п. 18.14 31 приказа
«Безопасность по
построению» – надежнее
и дешевле
18.14. Меры по обеспечению безопасной разработки прикладного и специального программного обеспечения
должны обеспечивать выявление, анализ и устранение разработчиком уязвимостей программного
обеспечения автоматизированной системы управления, определенного заказчиком, на всех этапах (стадиях)
его разработки, а также контроль принимаемых мер по выявлению, анализу и устранению уязвимостей со
стороны заказчика и (или) оператора автоматизированной системы управления.
20. Безопасная разработка: база уязвимостей
Регулируемые правила
ЖЦ уязвимости
Мониторинг
уязвимостей продуктов
и компонентов
Единая база фактов и
понятий
Устранение «пробелов»
в процессе безопасной
разработки
(эксплуатации)
21. Пересечение требований: 31-й приказ + СОПКА + безопасная разработка
идентификацию и аутентификацию субъектов
доступа и объектов доступа;
управление доступом субъектов доступа к
объектам доступа;
ограничение программной среды;
защиту машинных носителей информации;
регистрацию событий безопасности;
антивирусную защиту;
обнаружение (предотвращение) вторжений;
контроль (анализ) защищенности информации;
целостность автоматизированной системы
управления и информации;
доступность технических средств и информации;
защиту среды виртуализации;
защиту технических средств и оборудования;
защиту автоматизированной системы и ее
компонентов;
безопасную разработку прикладного и
специального программного обеспечения;
управление обновлениями программного
обеспечения;
планирование мероприятий по обеспечению
защиты информации;
обеспечение действий в нештатных
(непредвиденных) ситуациях;
информирование и обучение персонала;
анализ угроз безопасности информации и рисков от
их реализации;
выявление инцидентов и реагирование на них
(управление инцидентами);
управление конфигурацией автоматизированной
системы управления и ее системы защиты.
В соответствии с 31-м приказом необходимо обеспечить
22. Новая Информационная Безопасность
Зафиксировать проблему
Технический анализ – большие данные
Несистематизированные данные -
публикация информации об уязвимости
Сети обмена информацией об
уязвимостях
Обращения пользователей
Анализ, интерпретация
Скорость реакции - сократить «окно
уязвимости»
Анализ с учётом контекста
Локализовать и ограничить
В пространстве – свои и чужие ИС
Во времени - ретроспективный анализ
Устранение причин
Фундаментальное, надежное
Устранение аналогичных проблем
Анализ предпосылок
Безопасность создаваемых ИС
Доверие к продуктам и компонентам
Доверие к процессу разработки
Встроенная ИБ
Безопасность – общее дело:
обмен информацией
С пользователями
С ИБ сообществом
С ЦМ/CERT
Концептуальная безопасность
Практичные требования регуляторов
Концепция ИБ Industry 4.0
23. Потенциал совокупности требований
Соответствует актуальным угрозам
Замкнутая и полная система требований
Требования и проектирование
Разработка и тестирование
Эксплуатация
Мониторинг и реагирование
Акцент на практическую защищённость
Определены практические меры по реализации положений
Обратная связь (аудит, инциденты)
Актуализация требований
Взаимосвязь СЗИ, автоматизация процессов ИБ
24. Качалин Алексей
Директор ЗАО «ПМ»
@kchln
Kachalin@advancedmonitoring.ru
Аналитический и
инструментальный анализ ПО и ИС
Внедрение практик безопасной
разработки
Центр Мониторинга ИБ
ЗАО «Перспективный Мониторинг»
25.
26. ФЗ РФ от 21 июля 2011 г. N 256-ФЗ «О безопасности объектов
топливно-энергетического комплекса»
Статья 11. Обеспечение безопасности информационных систем объектов
топливно-энергетического комплекса
1. В целях обеспечения безопасности объектов топливно-энергетического
комплекса субъекты топливно-энергетического комплекса создают на этих
объектах системы защиты информации и информационно-
телекоммуникационных сетей от неправомерных доступа, уничтожения,
модифицирования, блокирования информации и иных неправомерных
действий и обеспечивают функционирование таких систем. Создание таких
систем предусматривает планирование и реализацию комплекса
технических и организационных мер, обеспечивающих в том числе
антитеррористическую защищенность объектов топливно-энергетического
комплекса.
2. Информация о системах, указанных в части 1 настоящей статьи, является
информацией, доступ к которой ограничен федеральными законами.
Указанная информация вносится в паспорта безопасности объектов
топливно-энергетического комплекса.
Hinweis der Redaktion
Недоволен регулятор
Априорная безопасность не тру
Недоволен регулятор
Априорная безопасность не тру
При создании Центров мониторинга необходимо не только установить и настроить СЗИ различного назначения, но и обеспечить их взаимоувязанную работу, агрегирование собираемой ими информации (в первую очередь, об обнаруженных компьютерных атаках, компьютерных вирусах и других инцидентах), а также её анализ (в том числе ретроспективный).
Таким образом, Центры мониторинга следует рассматривать, как совокупность СЗИ и единой консоли анализа и управления.
Событий по этапам
Сбор
Анализ СЗИ
Инциденты
ЦМ
Событий по этапам
Сбор
Анализ СЗИ
Инциденты
ЦМ
На ряду с созданием базового ресурса об актуальных угрозах безопасности информации и уязвимостях в программном обеспечении (банк УБИ ФСТЭК), нельзя не отметить разработанный но пока ещё не утверждённый стандарт по разработке защищенного ПО.
Цитата:
«Данный стандарт предназначен для разработчиков и производителей программного обеспечения в целях выполнения ими работ по созданию защищенного программного обеспечения, а также для организаций, выполняющих оценку соответствия процесса разработки программного обеспечения требованиям настоящего стандарта»
Т.е. оценку выполнения требований данного стандарта могут проводить организации занимающиеся практической ИБ.
Фактически, стандарт устанавливает наборы мер, которые должны быть выполнены в рамках процесса разработки ПО, а именно:
5.1 Меры, реализуемые при выполнении анализа требований к программному обеспечению
5.2 Меры, реализуемые при выполнении проектирования и детального проектирования архитектуры программного обеспечения
5.3 Меры, реализуемые при выполнении конструирования и комплексирования программного обеспечения
5.4 Меры, реализуемые при выполнении квалификационного тестирования программного обеспечения
5.5 Меры, реализуемые при выполнении инсталляции программного обеспечения и поддержки приемки программного обеспечения
5.6 Меры, реализуемые при решении проблем в программном обеспечении
5.7 Меры, реализуемые в процессе менеджмента документации и конфигурации программного обеспечения
5.8 Меры, реализуемые в процессе менеджмента инфраструктуры среды разработки программного обеспечения
5.9 Меры, реализуемые в процессе менеджмента людских ресурсов
Т.е. фактически в 31-приказе по защите АСУ ТП в п. 18.14, установлены требования по выполнению мер безопасной разработки
18.14. Меры по обеспечению безопасной разработки прикладного и специального программного обеспечения должны обеспечивать выявление, анализ и устранение разработчиком уязвимостей программного обеспечения автоматизированной системы управления, определенного заказчиком, на всех этапах (стадиях) его разработки, а также контроль принимаемых мер по выявлению, анализу и устранению уязвимостей со стороны заказчика и (или) оператора автоматизированной системы управления.
А данный ГОСТ, будет, в том числе, отвечать на вопросы, как эти меры выполнить и на каких этапах.
Требования предъявляемые к АСУ ТП в соответствии с 31-м приказом, идут в одном направлении с требованиями к СОПКА и мерам по безопасной разработке ПО. Особенно это видно из мер по обнаружение (предотвращение) вторжений и безопасной разработки прикладного и специального программного обеспечения.
Один из основных законов - Федеральный закон Российской Федерации от 21 июля 2011 г. N 256-ФЗ "О безопасности объектов топливно-энергетического комплекса", в нём много различных требований, но чаще всего обсуждают (фактически вопросы соответствия):
категорирование объектов топливно-энергетического комплекса;
формирование паспорта безопасности объекта топливно-энергетического комплекса.
Естественно, в нынешних реалиях в состав системы защиты объекта ТЭК должна входить подсистема обнаружения вторжений и реагирования на сетевые атаки. Т.е. объекты ТЭК должны так или иначе быть частью ГосСОПКА.