ИТ-пожарная безопасность: как минимизировать последствия кибератак в ритейле

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

Титаник ритейла: как компания может уйти на дно

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

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

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

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

Опыт интегратора: как восстановить крупную сеть после взлома

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

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

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

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

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

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

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

ИТ-пожарная безопасность: превентивные меры и сценарии восстановления

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

Чтобы снизить последствия атак, стоит адаптировать к ИТ подход, схожий с противопожарной безопасностью. «Пожарный план» в случае взлома должен включать в себя:

• заранее прописанные сценарии восстановления для каждой линии;
• распределение ролей и ответственность;
• договоры с хостинг-провайдерами на быстрое развертывание серверов;
• план подключения команд и подрядчиков по всей стране и типовые договоры.

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

В основе подобных мер лежит хорошо известный в отрасли DRP (Disaster Recovery Plan) — план восстановления после инцидентов. Но сегодня меняется сама природа угроз. Если раньше основная мотивация киберпреступников заключалась в краже данных и получении выгоды, то сегодня всё чаще на первый план выходят политические мотивы и стремление нанести компании максимальный ущерб. Поэтому сам подход к DRP необходимо пересматривать с учетом новых типов угроз и логики атак.

Тревожная коробочка: как продуманные бэкапы спасают бизнес

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

У нас в сфере ИТ существует своеобразная внутренняя классификация. Существует четыре типа компаний:

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

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

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

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

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

Страховка от взлома: что предпринять компаниям уже сейчас

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

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

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