Андрей Амирах, Security Vision: Снимаем боль от киберинцидентов и помогаем увидеть безопасность

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

За короткий срок, буквально за две-три недели, руководителям приходилось принимать решения о перестройке многих процессов на онлайн-формат, а также обеспечивать должный уровень кибербезопасности для сотрудников, работающих из дома. Остро стояли вопросы организации защищенного и функционального удаленного доступа, контроля за утечками информации, построения эффективных процессов онлайн-коммуникаций. Государственные регуляторы (ЦБ РФ, ФСТЭК России) своевременно, еще в начале массового перехода, выпустили свои рекомендации по обеспечению удаленного доступа для финансовых организаций и субъектов критической информационной инфраструктуры.Бизнес уходит в облако: стратегии и подходы

Коммерческие компании, не связанные законодательными требованиями в области ИБ столь сильно, имели больший простор для маневра, кроме того, у крупных и зрелых компаний были как готовые отлаженные процессы и инструменты удаленной работы, так и культура соответствующего формата деятельности. В конечном итоге, в большинстве случаев с технической точки зрения был реализован VPN-доступ к ограниченному набору сервисов компании и настроена мультифакторная аутентификация, а в качестве канала оперативной коммуникации использовались мессенджеры. Разумеется, внесенные в ИТ-инфраструктуру изменения, связанные с настройкой средств удаленной работы, потребовали и корректировки акцентов защиты: правил доступа на сетевом оборудовании, политик аудита ОС, правил корреляции SIEM-систем, плейбуков IRP-платформ и т.д.

Андрей Амирах: Удаленная работа для IT - в целом, норма, но в данной ситуации риски информационной безопасности были повышенными. Нехватка квалифицированных кадров в ИБ - не новость, поэтому тренд на автоматизацию ручных задач наметился уже достаточно давно. Реагирование на инциденты ИБ - это одна из самых очевидных задач, подлежащих роботизации, как в целях ускорения реагирования, так и в целях снижения рутинной нагрузки на аналитиков ИБ.

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

Возможность оперативно собрать необходимую информацию об инциденте ИБ, проанализировать и обогатить её, автоматически выполнить действия по локализации и устранению угрозы, запротоколировать все действия - вот главные козыри, которыми отвечали пользователи нашей IRP/SOAR-платформы повышенным угрозам ИБ во время пандемии. Компании, которые в рамках проведения анализа рисков ИБ учитывали частичную или полную недоступность офиса, уже заранее подготовили планы по обеспечению непрерывности деятельности, в том числе и с точки зрения процессов ИБ. Например, составление плейбуков для IRP-систем - это то, что нужно делать ДО наступления экстренной ситуации.

Андрей Амирах: Практика показала, что, к сожалению, даже у крупных территориально распределенных компаний не всегда присутствуют четкие формализованные плейбуки для реагирования на типовые инциденты ИБ (response playbooks). Когда мы приступаем к проведению пилотных внедрений нашей IRP/SOAR-платформы, как правило, у них «на бумаге» еще ничего нет. Поэтому приходится работать, записывая и формализуя действия команд реагирования путем опросов и интервью. В целом, это порочная практика, поскольку при реагировании на высокоприоритетный инцидент ИБ счет идет буквально на минуты, и это не то время, которое можно потратить на поиск свойств атакованной ИТ-системы или контактов ответственных за нее лиц. Приведу аналогию: во время пожара сотрудник должен точно знать, где находится огнетушитель и пожарный гидрант, где располагаются эвакуационные выходы, кто отвечает за процесс вывода людей из здания. Время играет против нас, ущерб увеличивается с каждой минутой. Имея четкий и понятный план действий, можно минимизировать негативные последствия и исключить совершение логических ошибок во время реагирования на ЧП.

Приходя к нашим заказчикам, мы помогаем формализовать процессы реагирования на инциденты ИБ, предлагаем пути автоматизации рутинных операций для экономии времени и ресурсов. Кроме того, внедрив нашу систему Security Vision IRP/SOAR, заказчики получают на отдельной вкладке каждой карточки инцидента ретроспективную детализированную историю действий специалистов ИБ при реагировании, благодаря чему появляется возможность оценить эффективность и корректность совершаемых операций, что особенно важно в критичные моменты.

Андрей Амирах: Конечно, идеи автоматизации системы управления ИБ не новы. В последнее время отчетливо виден еще и тренд на применение систем искусственного интеллекта (ИИ), технологий Big Data и машинного обучения при решении разнообразных задач, в том числе и при защите информации. Любой сотрудник, даже самый квалифицированный, при принятии решения может допустить ошибку, а если мы говорим про критичные процессы ИБ, то следует по возможности исключить такой «человеческий фактор», и это под силу как раз машинным системам. Обученные на большом количестве подходящих сэмплов данных, системы искусственного интеллекта могут принимать гораздо более взвешенные и корректные решения.

Мы предлагаем заказчикам нашу новую технологию auto-SGRC, которая, используя технологии ИИ и Big Data, расширяет горизонты автоматизации процессов ИБ. Классические системы класса SGRC (Security Governance, Risk Management and Compliance) предназначены для автоматизации решения задач управления ИБ, обеспечения риск-ориентированного подхода к ИБ и соответствия законодательным нормам и внутренним стандартам. Мы же решили, что необходимо добавить в данную схему столь необходимую обратную связь, при помощи которой можно автоматически корректировать настройки ИТ-активов и СЗИ, фактически частично использовав функционал нашей IRP-платформы.

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

Андрей Амирах: Кроме автоматизации процессов управления ИБ и реагирования на инциденты, достаточно актуальными являются вопросы соответствия законодательству, особенно в части защиты критической информационной инфраструктуры (КИИ) и защиты информации в финансовых организациях. Можем отметить повышенный интерес к нашим модулям интеграции с системами ФинЦЕРТ и ГосСОПКА. Данные модули позволяют автоматизировать отправку данных о произошедших инцидентах ИБ через API-интерфейс по заданной регуляторами форме и в соответствии с временнЫми нормативами.

Разнообразие форм отчетности, строгие сроки по их предоставлению и непрерывное изменение требований к их содержанию - вот что может затруднить выполнение комплайенс-процедур в организациях. Мы со своей стороны анализируем требования регуляторов, готовим актуальные формы отчетности, автоматизируем передачу данных об инцидентах ИБ из нашей IRP/SOAR-платформы в государственные системы (ФинЦЕРТ и ГосСОПКА) и тем самым существенно снижаем нагрузку на специалистов департаментов защиты информации. Это позволяет своевременно выполнять законодательные требования, не выходя за рамки регуляторных нормативов.

Андрей Амирах: Вопрос действительно интересный и однозначного ответа на него нет. С одной стороны, регуляторные требования достаточно конкретны: например, информацию о факте обнаружения инцидента ИБ на значимых объектах КИИ следует передавать в НКЦКИ в течение 3 часов с момента обнаружения, на незначимых - в течение 24 часов, и это вполне определенные временные метрики.

С другой стороны, последующее расследование самого инцидента может растянуться на месяцы и включать в себя привлечение антивирусных лабораторий, экспертов по компьютерной криминалистике и даже производителей скомпрометированных систем, если атака была осуществлена APT-группировкой. Поэтому мы склоняемся к мнению, что КПЭ логично измерять там, где процессы реагирования хорошо формализованы, т.е. на уровнях L1/L2 SOC-Центров. Можно измерять и анализировать время взятия инцидента в работу, сроки идентификации и первичной обработки (триажа), сбора дополнительной информации, локализации и устранения инцидента, а также принятия решения об эскалации инцидента на основании имеющегося playbook.

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