Здравствуйте.
Меня зовут Булат Гузаиров. Хотя зовут это слишком сильно сказано, обычно сам прихожу.
На Универсиаде я выполнял роль координатора группы проектов, которые выполняла наша компания
За благородно выделенные организатором 15 минут я вас расскажу про специфичную критических инфраструктуру – я назвал ее краткоживущей.
Мало того, что она краткоживущая, так она еще и критическая довольно ограниченное количество времени.
Что такое Универсиада для нас?
Перечень на слайде.
На самом деле было много чего вне ИТ – город менялся на глазах. Усиленные меры безопасности так или иначе также влияли на перемещения.
Хотя в итоге всю Универсиаду практически безвылазно просидели в Техническом Операционном Центре.
Спорно. Первое место однозначно считаем своей победой в том числе, т.к. наша компания занималась системой Аккредитации и соотв.
Наша компания на Универсиаде занималась не только ИБ, но и…
Система аккредитации, про значимость которой в наших победах я уже упомянул.
Здесь про специфическую специфику.
Для меня первый проект, на котором есть настоящий дедлайн. Не просто что-то показать высокопоставленным лицам, но и чтобы работало – никто начало Уни сдвигать не будет.
Хотя по факту многое сделать и не удалось как хотелось. В общем-то к началу Универсиады мы пришли в режиме тестовой эксплуатации, во время Универсиады провели опытную и 18-го июля сдали в промышленную. Только вот системы уже практически потушили.
Краткая жизнь. Системы должны были отработать 2 недели. По факту часть систем уже была не важна на самой Уни, т.к. свой функционал уже реализовали до начала – да, было много нервов и до начала мероприятия, но и требования по доступности для большинства систем были не такие жесткие. Так или иначе были обходные варианты работы по большинству автоматизированных процессов.
Государственное финансирование. То самое «по годам». Было довольно сложно планировать весь спектр работ, т.к. иногда до последнего не было понятно будут ли подтверждены деньги. От чего-то приходилось отказываться, что-то делать на свой страх и риск под обещания. Просто потому что дедлайн существует.
Большое число компаний. Очевидные вопросы в коммуникациях и выстраивании отношений. Во многом вопрос был больше в области эксплуатации и вывод основной оттуда же – единую поддержку надо было запускать минимум за полгода на притирку.
Часть систем к запуску проекта по ИБ была уже почти готова и нам фактически в бОльшей степени пришлось подстраиваться под текущие результаты, а не формировать требования. От формирования требований мы тоже не отказались, но по факту пришлось очень много времени потратить на поиск компромиссов. Где-то их найти не получилось. Например интеграционная шина и личный кабинет пользователей…
Так или иначе изменения происходили до последнего дня Универсиады
Наверное здесь нечего рассказывать.
Просто информационная справка.
Все указанные структуры были собраны в ТОЦ, т.е. коммуникации были самые что ни на есть прямые.
Еще чего-то рассказать
В определенной степени это банальные банальности.
Вынужденно пришлось пройти через оценку рисков и расставить приоритеты чем занимаемся в первую очередь.
Внутренних пользователей запугаем, значит акцент на внешние атаки.
Сайт Универсиады – лицо мероприятия, значит он должен жить.
Интеграционная шина архитектурно не позволяет нам снизить риски ее отказа – значит надо защищать.
Все остальное, если не мешает основным задачам – не критично.
Да, есть вирусы – они не влияют на работоспособность основных систем, значит нет смысла тратить время на их лечение.
Да, есть сервисы доступа в Интернет по WiFi. Мы не защищаем подключившихся – значит задача сводится к доступности на уровне ИТ. Обозначена потенциальная возможность отказа вследствие намеренного воздействия, но сам сервис признан малокритичным.
И т.д.
Задолго до Универсиады было понятно, что основные угрозы при подходах к разработке будут в области прикладных систем.
Соотв. команда Positive Technologies была привлечена к проекту весной 2013 года для анализа защищенности систем, доступных из сети Интернет.
Значительное число потенциальных уязвимостей было закрыто к самому мероприятию в результате этой работы.
Но мы понимали, что нам нужна поддержка компании специализирующейся на безопасности прикладных систем во время самой Универсиады.
И тут всю героичность и эпичность фактически задало то самое государственное финансирование – до 20.06. мы не знали будет ли одобрена работа Positive Technologies на Уни.
За неделю мы развернули дополнительные средства защиты в целях повышения наших возможностей по детектированию атак. Фактически это был дополнительный сервис на 4 недели в составе SIEM, AppFW
Соотв. хочу еще раз поблагодарить PT за оперативно проведенную работу по включению в SOC, а также корректировки в его работе с учетом собственного опыта.
Хоть в итоге нас толком никто и не атаковал (мы оказались никому не нужны), но в данной ситуации однозначно лучше перебдеть, чем недобдеть.
2 минуты
Здесь про основные особенности проекта – сроки, жесткая дата готовности, много параллельных процессов.
СИБ (в разрезе влияния на ИБ, без степени важности, просто перечнем):
-1. Хаос на объектах. Смещения сроков готовности и как следствие много чего уже делалось в режиме «лишь бы работало» без особых раздумий о последствиях (те же «левые» точки доступа или «левые» коммутаторы – многие из них оказались согласованными, но через СИБ, например, никак не проходили).
-2. Слишком поздно начали. Фактически для меня, например, старт работ октябрь 2012. Ноябрь улетел на заявки (очень, кстати, затратно). До этого в части СИБ по ощущениям ничего не делалось J. Соотв. в лучшем случае к январю начало появляться понимание во что попали и уже вывести проект из режима формальной безопасности к режиму «реальной» безопасности получилось далеко не во всем.
-3. Очень много компромиссов в связи с «-2». Многие системы уже были так или иначе реализованы к старту и пришлось с ними работать уже методом нашлепок, а не интегрированных решений. Сюда же группу раздолбайских подрядчиков, но тут уже компромиссы в связи с тем, что «запускать же надо, универсиаду не перенесут».
Выводы по указанным минусам:
1. Проект ИБ реально должен быть с самого старта, а не где-то посередине. Правила игры и требования должны быть заданы на старте. Понятно, что правила и требования могут меняться по пути, но не столь значительно.
2. На подобных проектах на старте нужно задаваться целью минимально зависеть от оконечных устройств и пользователей, т.к. контролировать их вряд ли кто-то сможет в такие сжатые сроки. Т.е. больший упор на анализ и согласование бизнес-логики и разграничение доступов в привязке к бизнес-логике, чтобы пользователь (по кр.мере их большая часть) не мог при всем желании нарушить правила.
+1. В принципе все-таки получилось аттестоваться. Здесь в плюс скорее все-таки то, что регуляторы во многом пошли на встречу.
+2. В принципе получилось подтянуть уровень ИБ АИС с точки зрения базового уровня. За счет тестов при сдаче и проверок уязвимостей перед УНИ.
+3. С точки зрения ИБ значимых инцидентов не было (не исключено, что оно просто никому было не нужно, но все же).
Выводы по указанным плюсам:
1. Со старта более плотно подключать регуляторов – показывать максимально на старте что недостижимо в принципе (то же использование сертифицированных ОС).
2. С самого начала вводить институт офицера ИБ, ставить цель вовлеченности в бизнес-процессы, а не управлять потом тем что получилось.