Метка: Кибербезопасность

UDV Group: Зрелость процессов против сложных инструментов — почему правильно организованные команды выигрывают

Опубликовано

Николай Нагдасев, ведущий специалист департамента кибербезопасности UDV Group

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

Когда технологии не работают: эффект отсутствия процессов

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

Характерный пример — внедрение полнофункционального SIEM-решения для покрытия распределенной или филиальной инфраструктуры. Инвестиции существенные, проект формально реализован, система развернута. Однако через год эксплуатации она продолжает работать в базовой конфигурации и фактически не влияет на уровень защищенности. Причина обычно лежит не в инструменте, а в отсутствии регламентированной операционной схемы: не определены роли и зоны ответственности, не закреплено, кто обрабатывает алерты первой линии, как осуществляется эскалация, в какие сроки происходит закрытие инцидентов. В результате поток событий накапливается, часть алертов остается без обработки, а критичность определяется на уровне субъективного решения специалиста.

Аналогичная ситуация наблюдается при внедрении решений класса VulnerabilИТy Management. Наличие сканера уязвимостей само по себе не означает появления процесса управления уязвимостями. Инструмент фиксирует текущее состояние инфраструктуры, но не обеспечивает закрытие выявленных проблем. Если не определены регламентированные сроки устранения, порядок ранжирования по критичности, процедура проверки применимости уязвимости к конкретной среде и механизм контроля повторного возникновения, решение начинает выполнять исключительно диагностическую функцию. Отчеты формируются, но реальный уровень защищенности остается прежним.

Почему инструменты «включили и забыли» перестают работать

Типовые ошибки в организации процессов часто приводят к тому, что функциональность ИБ-инструментов формально присутствует, но практически не используется.

Первая распространенная ошибка — подход «включили и забыли». Система информационной безопасности не является статичным оборудованием, которое можно установить и эксплуатировать без изменений. Любое решение требует регулярного тюнинга и адаптации. Инфраструктура компании развивается: появляются новые сервисы, меняются схемы взаимодействия, трансформируется архитектура. Одновременно эволюционирует и ландшафт угроз — появляются новые техники атак и способы обхода защитных механизмов. Если инструмент не адаптируется к этим изменениям, его эффективность постепенно снижается.

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

Еще одна типовая ошибка — отсутствие формализации и документирования. На практике часто система или отдельный процесс держатся на компетенции одного специалиста. В моменте это может работать эффективно, однако при увольнении или длительном отсутствии сотрудника инструмент фактически остается без владельца. Технология продолжает функционировать, но операционная логика ее использования теряется. Такая зависимость от персонального опыта создает управленческий риск.

Зрелая модель предполагает закрепленные роли, задокументированные процедуры и возможность воспроизводимости процессов независимо от конкретного исполнителя.

Как зрелость процессов влияет на требования к инструментам и архитектуре

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

Если компания развита технологически, ее потребности становятся сложнее. Однако при выборе инструментов ключевой вопрос — не «что умеет продукт», а «для какой задачи и в каком процессе он будет использоваться».

На примере SIEM это особенно заметно. Цель системы — не агрегировать события и демонстрировать корреляцию по базовым правилам, а выявлять инциденты, критичные именно для конкретной инфраструктуры, с учетом значимости активов и сценариев атаки. Без четкого понимания процессов SIEM превращается в хранилище логов с минимальным прикладным эффектом.

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

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

Почему распределение ролей важнее сложности инструментов

Процессы информационной безопасности почти всегда пересекают несколько подразделений. ИТ отвечает за инфраструктуру и доступность сервисов, производственные или бизнес-направления — за прикладные системы и технологические сегменты, ИБ — за выявление угроз и ограничение распространения атак. На границах этих зон и возникают основные риски.

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

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

Какие метрики действительно отражают зрелость процессов

Определить зрелость процессов только по наличию регламентов невозможно. Формально описанный процесс может существовать на бумаге, но не работать на практике. Реальную картину дают операционные и результативные метрики.

Если говорить о процессе управления инцидентами, стандартный набор показателей делится на две группы. К операционным относятся время обнаружения, реагирования и восстановления, количество инцидентов в работе и их распределение по критичности. Эти метрики показывают загрузку и темп работы команды. Метрики эффективности отражают качество процесса. Это процент ложных срабатываний, доля инцидентов, закрытых в рамках SLA, количество повторных инцидентов и процент случаев, по которым проведен анализ коренных причин.

Ключевыми индикаторами зрелости можно считать несколько показателей.

  1. Среднее время обнаружения. Насколько быстро команда понимает, что инцидент действительно происходит.
  2. Среднее время реагирования, то есть интервал от обнаружения до фактического сдерживания или остановки атаки.
  3. Количество повторных инцидентов. Если схожие сценарии регулярно воспроизводятся, значит первопричина не устранена. Зрелая модель предполагает не только закрытие инцидента, но и изменение конфигураций, политик или настроек средств защиты для предотвращения повторения.

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

Именно динамика этих метрик, а не их разовое значение, позволяет судить о том, что процесс развивается и становится зрелым. Однако сами по себе метрики не повышают устойчивость — они лишь фиксируют состояние системы. Возникает практический вопрос: какие управленческие и инженерные шаги позволяют улучшать эти показатели без постоянного расширения технологического стека?

Как повысить эффективность команды без усложнения технологического ландшафта на примере процесса управления инцидентами

Первый элемент — формализация сценариев реагирования. Задача не должна звучать абстрактно как «расследовать инцидент». Для типовых ситуаций (заражение вредоносным ПО, компрометация учетной записи, попытка несанкционированного доступа и т.д.) должна быть зафиксирована согласованная последовательность действий. Фактически речь идет о чек-листах: изолировать хост, собрать артефакты, проверить хеши, зафиксировать события, инициировать восстановление. Такой подход снижает зависимость от субъективной интерпретации и позволяет отслеживать выполнение каждого шага.

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

Третья практика — регулярные киберучения и тренировки. Они позволяют проверить работоспособность сценариев, оценить готовность команды и выявить узкие места без наступления реального инцидента. Такой формат дает объективную картину задержек, несогласованности действий и проблем эскалации. В результате корректировки вносятся проактивно, а не в условиях кризиса.

Эти практики усиливают управляемость без расширения технологического стека. В зрелой модели сначала настраивается дисциплина исполнения и воспроизводимость процессов, и только затем принимаются решения о расширении инструментов. Игнорирование этой последовательности и приводит к одной из самых распространенных управленческих ошибок — масштабированию ИБ за счет новых решений при сохранении прежней организационной модели.

Ошибки масштабирования: когда инструменты подменяют процессы

Одна из самых распространенных ошибок — попытка решить организационный хаос технологическим способом. Если в компании не выстроен процесс управления инцидентами, отсутствуют закрепленные роли и понятная эскалация, появление нового инструмента не устранит эти пробелы. Например, руководство видит, что команда не справляется с потоком событий, и принимает решение внедрить SIEM или EDR, рассчитывая, что система «сама найдет и расследует» угрозы.

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

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

Заключение: три принципа, чтобы инструменты усиливали процессы, а не подменяли их

Если обобщить практику внедрения ИБ-решений, можно выделить несколько принципов, которые стоит зафиксировать на управленческом уровне.

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

Второй принцип — инструмент не компенсирует управленческие проблемы. Конфликт полномочий, размытые зоны ответственности или отсутствие регламентов не устраняются внедрением новой платформы. Более того, сложное решение в такой среде способно усилить напряжение, добавив новые точки контроля и споров. Управленческие вопросы должны быть решены до масштабирования технологического ландшафта.

Третий принцип — простота как индикатор зрелости. Зрелость не измеряется количеством экранов в центре мониторинга или объемом внедренных решений. Она определяется тем, насколько короткой и понятной является цепочка действий от обнаружения угрозы до ее нейтрализации. Архитектура и инструменты должны сокращать эту цепочку, делать процессы прозрачными и воспроизводимыми.

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

Источник: https://www.novostiitkanala.ru/news/detail.php?ID=194276

UDV Group: AI Security — безопасность искусственного интеллекта

Опубликовано

Юрий Чернышов, к.ф.-м.н., доцент УНЦ «Искусственный интеллект» УрФУ, руководитель исследовательского центра UDV Group рассказал о сложностях обнаружения причины изменения поведения модели, о методах, которые подходят для анализа безопасности и о том, как оценивается устойчивость модели в условиях реального применения.

— Какие индикаторы помогают заметить ранние признаки отравления данных на этапе подготовки датасета?

Почти все, кто имеет практический опыт внедрения и использования проектов, включающих анализ данных и машинное обучение, уже в курсе, что подобные системы очень неустойчивы, чувствительны к внешним помехам. Причина этого не в том, что у разработчиков недостаточная экспертиза (хотя встречаются и такие случаи), а в том, что при обучении модели применяются наборы данных, которые не могут содержать все возможные ситуации при будущей эксплуатации. Да это и невозможно, поскольку всегда на практике имеет место так называемый «сдвиг в данных» (data shift) из-за меняющейся инфраструктуры, условий эксплуатации, поведения пользователей и пр. Поэтому очень сложно при обнаружении изменения поведения модели понять — что же является истинной причиной: сдвиг в данных, сбой датчика, помехи в сети передачи данных, некачественная модель ML, незначительная перегрузка инфраструктуры или это просто «шум» в рамках статистической погрешности. И за этими вариантами всегда сложно разглядеть атаку через отравление данных. Индикаторы для диагностики изменения традиционные: всесторонний статистический анализ характеристик данных, как по параметрам получения и обработки, так и по семантике. Но для принятия мер при обнаружении отклонения в поведении модели на основе данных необходима комплексная инфраструктура, включающая мониторинг оборудования, параметров данных и модели, метрик инференса (промышленного использования).

— Какие методы анализа позволяют выявлять бэкдор-активность в уже обученной модели?

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

— Как оценивается устойчивость модели к adversarial-примерам в условиях реального применения?

Самый лучший способ для подобного анализа это red teaming, в том числе и с применением автоматизированных средств проверки: фаззинг, подбор проверяющих сэмплов, создание для модели критических условий для функционирования (ddos атака). Если есть возможность оценивать устойчивость в лабораторных условиях, то эффективным является схема генеративных состязательных сетей (GAN), в которых есть генератор, создающий сэмплы, и дискриминатор, пытающийся различить настоящие сэмплы и созданные генератором. При этом генератор и дискриминатор постоянно конкурируют друг с другом, генератор учится все лучше «обманывать», а дискриминатор – все лучше выявлять факт подделки.

— Какие техники усложняют попытки извлечения модели через API (model extraction)?

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

— Какие меры повышают защищенность датасетов от подмены, injection-атак и несанкционированных правок?

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

— Какие механизмы мониторинга лучше всего подходят для отслеживания аномалий в поведении ИИ-модели?

Существует множество способов мониторить работу сложного устройства или системы, какой из них наиболее эффективен – сильно зависит от самой системы. Можно анализировать низкоуровневые параметры (трафик, потребление ресурсов оборудования), можно анализировать вход и выход модели ИИ (текст промпта и сгенерированный ответ), потребление токенов. Но на мой взгляд наиболее эффективно анализировать влияние применения модели на бизнес-процесс – если в бизнес-процессе появились отклонения (изменилась продолжительность звонков, частота отправки писем, поменялась бизнес-логика процесса, перестал компилироваться код и пр.), то скорее всего случился сбой в работе ИИ-модели и необходимо проводить расследование, в том числе с применением анализа низкоуровневых событий в инфраструктуре и ПО.

UDV Group: выстраиваем зрелую систему ИБ в условиях ограничений рынка

Опубликовано

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

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

Какие ошибки на старте начинают проявляться через один–два года эксплуатации? И какие принципы позволяют сохранить устойчивость ИБ в долгосрочной перспективе? Об этом – в колонке Николая Нагдасева, ведущего специалиста департамента кибербезопасности UDV Group.

Три кита зрелой системы информационной безопасности

На практике все эти вопросы сводятся к одному: что делает систему ИБ управляемой и устойчивой не в теории, а в реальной эксплуатации? Опыт крупных российских компаний показывает, что при всём разнообразии отраслей и ИТ-ландшафтов принципы построения зрелой системы ИБ во многом совпадают.

Если говорить упрощённо, в таких организациях зрелая система информационной безопасности опирается на три базовых элемента.

Первый элемент – люди, их компетенции и выстроенные вокруг них процессы. Речь идёт не просто о наличии специалистов по ИБ, а о том, как организованы отдельные процессы: безопасность сетевого периметра, антивирусная защита, мониторинг, управление уязвимостями, реагирование на инциденты и т.д. За каждым процессом стоят конкретные зоны ответственности и понятные правила взаимодействия между ИБ, ИТ и бизнесом. Без этого компания быстро скатывается в реактивную модель с постоянным «тушением пожаров».

Второй элемент – архитектура и документы. Это инженерная основа системы: инвентаризация активов, модели угроз, сетевая сегментация и понимание потоков данных. Политики и регламенты по ключевым направлениям ИБ формализуют единые правила игры и позволяют связать отдельные меры в целостную систему. Без этой основы безопасность перестаёт быть управляемой и начинает фрагментироваться.

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

С чего начинать построение ИБ, если весь стек внедрить невозможно

Если невозможно внедрить весь стек решений по информационной безопасности сразу, начинать стоит не с перечня конкретный средств зищиты, а с понимания контекста. Архитектура ИБ всегда должна учитывать особенности конкретной компании – универсальных рецептов здесь не существует. Отправной точкой становятся критичные бизнес-процессы и связанные с ними информационные системы. Именно они задают приоритеты защиты и определяют, какие меры действительно важны для устойчивости бизнеса. Кибербезопасность выстраивается не абстрактно, а с фокусом на последствия для ключевых процессов.

С архитектурной точки зрения базовым шагом остаётся сегментация сети и выстраивание эшелонированной защиты. Задача – изолировать наиболее критичные активы и снизить риск распространения атак внутри инфраструктуры. С технической стороны средства защиты логично рассматривать по слоям. Базовый слой включает антивирусную защиту, межсетевое экранирование, резервное копирование, защиту веб-приложений, безопасность удалённого доступа и двухфакторную аутентификацию для критичных и ресурсов, доступных из сети интернет. Сегодня к этому минимуму в полной мере относятся инструменты для сканирования уязвимостей внешнего периметра и критичных систем, а также использование SIEM-функциональности для централизованного анализа событий безопасности.

Следующий уровень напрямую зависит от зрелости компании и готовности процессов. Здесь появляются системы управления привилегированным доступом, платформы управления инцидентами и собственный или внешний SOC.

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

К чему приводят архитектурные компромиссы в проектах по построению ИБ

Ограничения рынка почти неизбежно приводят к архитектурным компромиссам, и их последствия, как правило, проявляются не сразу, а через год–два эксплуатации.

Одна из наиболее частых ошибок – внедрение точечных решений без учёта общей архитектуры системы безопасности. Формально задачи закрываются, но на практике компания получает набор слабо связанных инструментов, которые сложно сопровождать и ещё сложнее развивать. Это увеличивает операционную нагрузку и снижает управляемость системы ИБ. Ситуацию усугубляет дефицит специалистов. Нередко решения оказываются внедрёнными, но не обеспеченными ресурсами для полноценной эксплуатации. В результате средства защиты не дают ожидаемого эффекта, а инвестиции в ИБ фактически не работают. Чтобы этого избежать, архитектуру системы безопасности необходимо проектировать с учетом реальных возможностей эксплуатации и заранее продумывать связность решений, как минимум на уровне мониторинга и управления.

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

В долгосрочной перспективе ключевая задача – не допустить превращения ИБ в разрозненный набор решений с высокой операционной нагрузкой. Иначе рост эксплуатационных затрат будет сопровождаться снижением реального уровня защищённости.

Как выстраивать приоритеты между предотвращением, мониторингом и реагированием

В условиях ограниченных ресурсов важно не пытаться развивать все направления одновременно, а выстраивать последовательную логику. Начинать стоит с предотвращения. Предотвращение – стратегическая цель, но достигается она через вполне прикладные меры: сегментацию сети, своевременное обновление систем, харденинг и регулярное устранение уязвимостей. Эти действия снижают вероятность инцидентов ещё до этапов обнаружения и реагирования.

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

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

Обнаружение логически вытекает из мониторинга и зависит от качества данных и процессов анализа. Уже на этой базе становится возможным управляемое и воспроизводимое реагирование на инциденты.

Почему наблюдаемость становится базовым требованием зрелой ИБ

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

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

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

Для ИТ-директора при дефиците инструментов и специалистов критично держать под контролем два блока данных: перечень критичных бизнес-процессов и обеспечивающих их систем, а также сводный статус выполнения базовых мер защиты – обновлений, закрытия уязвимостей, охвата двухфакторной аутентификацией, выявленных инцидентов и выполнении технических мер по защите информации.

Какие процессы ИБ стоит автоматизировать в первую очередь

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

В первую очередь это касается управления инцидентами. На этапе анализа автоматизация ускоряет обогащение инцидентов контекстом за счёт данных из внутренних систем и средств защиты. На этапе реагирования она позволяет сократить время реакции и повысить точность и воспроизводимость действий – от блокировки учётных записей и обновления правил фильтрации до изоляции скомпрометированных узлов.

Почему без правильной эксплуатации система ИБ неизбежно деградирует

Зрелость информационной безопасности определяется не наличием отдельных средств защиты, а тем, насколько устойчиво и предсказуемо выстроены процессы управления информационной безопасностью компании. Именно на этапе эксплуатации чаще всего возникают проблемы, которые со временем подтачивают систему ИБ. Инфраструктура постоянно меняется: появляются новые сервисы, обновляются ИТ-системы, меняются конфигурации. Если система информационной безопасности не развивается синхронно с этими изменениями, возникают обходы политик, устаревшие регламенты и неактуальные настройки средств защиты. Формально ИБ существует, но всё хуже отражает реальное состояние инфраструктуры.

Чтобы этого избежать, необходим регулярный контроль и тестирование безопасности, прежде всего для точек входа в инфраструктуру, ресурсов доступных из сети Интернет и критичных информационных систем. Такой контроль позволяет выявлять расхождения между требованиями и фактическими настройками до того, как они приведут к инциденту. Не менее важна жёсткая связка ИБ с процессами изменения ИТ-инфраструктуры. Любые внедрения, миграции и обновления должны проходить оценку с точки зрения ИБ и соответствия действующим политикам. Дополняют эту модель регулярные тренировки по реагированию на инциденты, максимально приближённые к реальным сценариям. Они помогают поддерживать навыки команды и выявлять слабые места в процессах и технологиях, которые не всегда видны при формальном анализе.

Какие принципы стоит зафиксировать, чтобы система ИБ оставалась устойчивой

В долгосрочной перспективе устойчивость системы информационной безопасности определяется не столько текущим набором средств защиты, сколько принципами, заложенными в архитектуру изначально. Эти ориентиры важно зафиксировать заранее, независимо от рыночных условий.

Первый принцип – технологическая автономия и отказ от жёсткой зависимости от одного вендора. Архитектура ИБ должна учитывать ограничения поставок, изменения условий поддержки и возможный уход решений с рынка. Монолитные экосистемы могут ускорять внедрение, но в долгосрочной перспективе вендор-лок увеличивает риски для устойчивости системы.

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

Отдельного внимания требует готовность к инцидентам. В компании должен существовать понятный план реагирования, а его эффективность необходимо регулярно проверять на практике – через учения и тренировки, приближённые к реальным сценариям.

Наконец, устойчивость невозможна без измеримости. Метрики состояния защищённости позволяют объективно оценивать эффективность мер ИБ, управлять рисками и обосновывать инвестиции как внутри ИТ, так и на уровне бизнеса и руководства.

Заключение

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

Источник: https://globalcio.ru/discussion/57732/

UDV Group: новые реалии ransomware-атак

Опубликовано

Виталий Рабец, директор ИТ департамента UDV Group рассказал о том, что ransomware-атаки на российский бизнес приобретают новые формы: злоумышленники все чаще используют репутационный шантаж, атаки через подрядчиков и сложные схемы психологического давления, а также объяснил, почему в первые часы после инцидента нельзя отключать системы без подготовки.

— Какие новые техники вымогателей вы наблюдали в последних атаках на российский бизнес (например, угроза DDoS-атакой, звонки партнёрам и клиентам, публикация данных в даркнете с аукционом)?

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

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

— Если отбросить стандартный совет про «бэкапы», какой класс защиты или конкретная мера, по вашему опыту, наиболее эффективно предотвращает распространение шифровальщика внутри сети после первоначального проникновения?

Лучшая защита от распространения любого вируса внутри сети — это строгое разграничение сетей по VLAN. Изоляция критически важных серверов и, в целом, сегментация. Также немаловажным является строгий контроль учётных записей и их доступов к файлам и ресурсам. Точкой входа для проникновения может быть компьютер рядового сотрудника, но если пользовательская сеть отрезана от сети с критичными данными, а доступы учётных записей строго ограничены, то это сильно усложнит распространение шифровальщика и, в целом, возможности злоумышленников для дальнейшего развития атаки.

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

— Каков пошаговый алгоритм действий в первые 24 часа для команды реагирования, помимо отключения систем? На что чаще всего не хватает времени или ресурсов, что усугубляет последствия?

Я бы сказал, что «отключение систем» — не совсем правильное действие. Системы нужно отключать постепенно и с умом. Отключение «всего сразу» может привести к потере важных данных и логов, которые хранятся в памяти и будут очень нужны для дальнейшего расследования инцидента. Первое и очень важное — выявить точку входа. Найти нулевого пациента, и именно его нужно изолировать в первую очередь. Параллельно, и не менее важно, остановить все процессы репликации данных. Все бэкапы, дампы и создание любых резервных копий нужно срочно прекратить. После этого необходимо сохранить все логи и сделать дампы важной для расследования информации. И только после этого стоит «отключать системы».

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

Далее уже процедура вполне стандартная — анализ логов и развёртывание полномасштабного расследования.

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

— Был ли у вас или ваших коллег опыт переговоров с вымогателями? Какие выводы или тактические приёмы можно из этого извлечь?

Опыт был. Самое важное — не поддаваться панике и не вестись на провокации. Злоумышленники в 100% случаев будут пугать вас тем, что захватили полный, стопроцентный контроль, что всё в их власти и что последствия ужасны и невообразимы. По факту же, в моём частном случае, это оказалось чистым блефом, а данные, к которым получили доступ хакеры, были неважные и совершенно не давали им никакого контроля над системой.

Добавлю, что во время переговоров со злоумышленниками важно тянуть время, отвечать лояльно, не провоцировать и прикидываться ничего не понимающей жертвой, чтобы усыпить бдительность злодеев настолько, насколько это возможно, в первую очередь — чтобы выиграть время на оценку масштабов проникновения и заражения.

— Какой самый неочевидный, но критически важный шаг при восстановлении инфраструктуры после ransomware-атаки, о котором часто забывают?

О нём я, наверное, уже писал выше — это определить порядок восстановления. Восстанавливать сервисы необходимо по порядку критичности, начиная с самых неважных. Об этом часто забывают, потому что самое критичное нужно для работы уже «прямо сейчас», и сотрудники не могут ждать простоя важных сервисов — всем нужно работать, ведь бизнес теряет деньги.

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

  1   2   3   4   5   6   7   8   9   10   11  »

Пользовательское соглашение

Опубликовать
Яндекс.Метрика