The post has been translated automatically. Original language: Russian
In early August, several major European brands learned that their
customer data had been leaked, although no one had hacked the companies themselves.
The entry point turned out to be in a different place: at the logistics operator CEVA, which
he kept their inventory records and fulfillment. The attack hit several warehouses
in Europe, some shipments stopped, and the brands whose data was stored there
were embroiled in a story that was not formally related to them -
no one touched their own perimeter. This
is not a rare case, but a fairly typical recent scenario:
attackers no longer need to break into the company itself if they can
log in through someone who has legitimate access to its data -
a contractor, a cloud provider, a developer, or logistics.
One such
hack gives access to dozens of supplier's clients at once, and from
the attacker's point of view, it is simply more profitable than breaking each one individually.We
are not dealing with this topic abstractly. We have projects where we
work with sensitive data not directly, but through a chain -
an agency, a partner, a third integration. And the question "what if they break not
us, but someone from those with whom we are integrated" is not
at all hypothetical, especially when it comes to public services, where
The leak is not hitting the company, but specific people.What's with this anyway
is it possible to do this in practice if you are not CEVA Logistics or a bank with
a separate information security department? Honestly, there's not much that's perfect, but something
really works. First, treat the contractor's access in the same way as
your own employee's access - the minimum necessary, with
logging, and not "well, he's a partner, he can do anything."
Secondly, asking
suppliers is not a common phrase about "we are serious about
security", and specifics - where the data is stored, who has access, what
happens during an incident.If they can't answer this question directly
, that's the answer. The third, most boring and most workable thing is segmentation. If
the contractor does not have access to everything at once, hacking one link does not
turn into a leak of everything.None
of this cancels the attacks completely, and they cannot be undone. But the difference
between "some of our data leaked through the contractor" and "everything leaked
because we gave the contractor access to everything" is the difference that
you can design it in advance before the thunder hits.
В начале августа несколько крупных европейских брендов узнали, что их
клиентские данные утекли - хотя сами компании никто не взламывал. Точка
входа оказалась в другом месте: у логистического оператора CEVA, который
вёл их складской учёт и фулфилмент. Атака ударила по нескольким складам
в Европе, часть отгрузок встала, а бренды, чьи данные там хранились,
оказались втянуты в историю, к которой формально не имеют отношения - их
собственный периметр никто не трогал. Это
не редкий случай, а довольно типичный сценарий последнего времени:
злоумышленникам больше не обязательно ломать саму компанию, если можно
зайти через кого-то, у кого есть легитимный доступ к её данным -
подрядчика, облачного провайдера, разработчика, логистику. Один такой
взлом даёт доступ сразу к десяткам клиентов поставщика, и с точки зрения
атакующего это просто выгоднее, чем ломать каждого по отдельности.
Мы
сталкиваемся с этой темой не абстрактно. У нас есть проекты, где мы
работаем с чувствительными данными не напрямую, а через цепочку -
ведомство, партнёр, третья интеграция. И вопрос "а что если сломают не
нас, а кого-то из тех, с кем мы интегрированы" - совсем не
гипотетический, особенно когда речь о государственных сервисах, где
утечка бьёт не по компании, а по конкретным людям.
Что с этим вообще
можно сделать на практике, если вы не CEVA Logistics и не банк с
отдельным департаментом ИБ? Честно - не так много идеального, но кое-что
реально работает. Первое: относиться к доступу подрядчика так же, как к
доступу собственного сотрудника - минимально необходимый, с
логированием, а не "ну он же партнёр, ему можно всё". Второе: спрашивать
у поставщиков не общие слова про "мы серьёзно относимся к
безопасности", а конкретику - где хранятся данные, кто имеет доступ, что
происходит при инциденте.
Если на этот вопрос не могут ответить прямо -
это уже ответ. Третье, самое скучное и самое рабочее: сегментация. Если
у подрядчика нет доступа ко всему сразу, взлом одного звена не
превращается в утечку всего.Ничего
из этого не отменяет атаки полностью - их и не отменить. Но разница
между "у нас утекла часть данных через подрядчика" и "у нас утекло всё,
потому что мы дали подрядчику доступ ко всему" - это разница, которую
можно спроектировать заранее, пока гром не грянул.
Share
