Из просочившейся в медиа информации интерес представляет заявление представителя “хакеров”, заявившего что «криворукие админы с маленькой зарплатой делали бэкап раз в полгода».
Что немедленно начали опровергать разнообразные “эксперты”. Для примера приведём заявление одного из них:
“Специалист по информационной безопасности (ИБ) ******* отметила, что в компании со зрелыми ИБ-департаментами резервное копирование выполняется автоматически. Например, нередко отдельные изменения базы данных резервируются каждые 15 минут, а полное копирование происходит раз в месяц.
«Такая компания, как СДЭК, наверняка делает бэкапы регулярно и хранит их на отдельных мощностях, поэтому шифровальщик не должен был до них добраться.”
Как говорится, не должен был, но добрался. Корень проблемы кроется как раз в “отдельных мощностях”. Добраться вирус, как любая программа может куда угодно внутри информационной системы. Кроме физически отключённого от неё носителя. То есть лежащей в сейфе резервной копии на стриммерной ленте.
Здесь проявилась первая часть жадности и почти вся лень. Судя по всему, вместо того, чтобы обзавестись системами резервного копирования для всех узлов, ИБ пожадничала и сливала файлы куда нибудь типа выделенного сервера или вообще в облако. Добраться куда и вообще всё там стереть проблемы не составляет.
Всё это происходило вместо того, чтобы, как у нормальных и ответственных, сгонять бекапы на ленты и относить их в дата-сейфы. Вот здесь лень проявилась во всей красе. Это же надо делать ручками и ножками. Да ещё карандашом маркировать каждую ленточку. Про дороговизну которых можно не говорить. Облако обходится на порядки дешевле.
Мы не ставим задачи разобраться в устройстве чужой инфосистемы, хотя наш It департамент, почитав про специфические подробности этой истории на профильных ресурсах, продемонстрировал неслыханные ранее обороты обсценной лексики. Вся ценность логистической компании заключена в трёх “ящиках”:
- клиентской базе
- журнале транзакций
- управляющем текущими операциями софте
Утратить последний практически невозможно, только если имела место откровенная диверсия. Принимая во внимание то, откуда родом отличившиеся хакеры, высока вероятность, что поддержкой ПО занимались их коллеги, которые и подготовили базу для атаки. Хотя откат на пару апдейтов назад скорее всего помог бы. Частичная утрата функциональных новаций, скорее всего, не может быть критичной.
Единственная нетривиальная задача заключается в поиске “закладок” в коде. Это можно было бы реализовать, если бы сами резервные копии ПО хранились не на сервере, где они могут быть легко удалены или повреждены, а в сейфе. Который нужен совсем маленький. Например такой:
С клиентской базой всё сложнее, но так же не может быть фатально. При грамотной организации резервного копирования максимум, что можно потерять - это данные за последний день. Которые несложно восстановить в ручном режиме, воспользовавшись логами как мобильных операторов, так и электронной почты. Да и сами “потерявшиеся” помогут. Причём нанести какие-то фатальные повреждения этим данным невозможно.
Масштаб клиентской базы понятен и её резервирование не требует колоссальных затрат. Наибольший риск заключается не в утрате, а в утечке персональных данных. За что, кстати, текущим законодательством предусмотрена ответственность вплоть до уголовной. Кстати, обработку и хранение персональных данных должен проверять некий госорган. По все видимости он спал. При том, что это уже было:
Самая сложная и затратная задача заключается в хранении записей о транзакциях. В которые сами по себе невозможно внести какие-либо зловредные изменения. Зато их утрата отправит компанию в каменный век. То есть в необходимость всё восстанавливать руками.
При этом резервирование журналов транзакций должно выполняться не столько централизованно, сколько распределённо. То есть каждый пункт выдачи должен быть оснащён одним стриммером, парой десятков лент (количество зависит от политики соотношения полных и инкрементных бекапов) и одним дата сейфом. К примеру таким:
Ни для кого не является секретом количество пунктов выдачи СДЕКа. Зная, со своей стороны рынок сейфов, можем сказать, что ничего подобного никто не закупал. Причём цена вопроса не такая большая, а трудозатрат на каждый пункт, при самом дотошном исполнении всех необходимых процедур, в день не может быть больше одного человеко-часа. Хотя, при нормальных айтишниках всё можно на 95% загнать в фоновые задачи и физическому сотруднику пункта выдачи останется только процедура вставить ленту в стриммер утром, вытащить её вечером и убрать на ночь в сейф.
А так как ничего из вышеописанного явно не делалось, то нам всем как раз и продемонстрировали, к чему приводит сочетание жадности и лени.
PS. Для любителей IT. Атака подобного типа осуществляется двумя путями. Либо "зловредное" ПО заносит инсайдер. Это может быть как собственный сотрудник, так и работающий на удалёнке фрилансер-разработчик. Бороться с этой категорией довольно сложно. Со "своим" должна разбираться СБ, тем более что камер наблюдения везде через край. Хотя жадность и здесь могла себя проявить.
С удалённым разработчиком и поддержкой бороться (и контролировать их) несложно. Нужно хотя бы не оставлять открытыми каналы связи, когда они закончили. А то удивительная манера всех обленившихся держать постоянно открытым 22-й порт, рано или поздно приводит к появлению нежелательных гостей.
Второй путь подобных атак основан на электронной почте. Эти атаки осуществляются веерно и постоянно. Предохраняться надо на уровне организации внутренней системы передачи сообщений. Надо помнить, что каналом распространения вирусов шифровальщиков являются в основном файлы word и excel. В "плоский" текст или базу данных (нормально структурированную) внести какие-то незаметные изменения, содержащие посторонний исполняемый код просто невозможно.
Вся информация, которая циркулирует внутри компаний с распределённой структурой, должна исключать такие документы (Микрософт это вообще зло) и ограничиваться либо просто текстом, либо ссылками на записи в БД. А у серверных решений, при должном и довольно несложном уровне администрирования, нет больших дырок в безопасности.
PPS. А вот ещё и "Верный" завалился. С точно таким же диагнозом - уничтожение резервных копий.
