Следи за собой, будь осторожен
Хакерское ремесло в конце 2024 года выглядит как занятие для весьма средних умов. Методики атак описаны на специализированных форумах, а эксплойты купить не сложнее, чем подписку на какой-нибудь музыкальный или видеосервис. Однако низкий «интеллектуальный ценз» — всего лишь один из факторов развития киберпреступности. Другой — и, возможно, более определяющий — это удивительная беспечность организаций-жертв.
«Да кому мы нужны?!» Эту реплику я и мои коллеги слышим регулярно в ответ на рекомендацию выполнить хотя бы «гигиенический минимум» корпоративного кибербеза. Но по-настоящему странно, когда нечто подобное высказывают реальные жертвы кибернападений. Они уже прошли и зашифрованные данные, и оплату отступных. Но все равно считают реализовавшуюся атаку случайным эпизодом. «Вторая бомба в ту же воронку не попадает», — говорят представители компаний-жертв. Статистика, впрочем, утверждает обратное: в четырех случаях из пяти киберпреступники наносят удар по жертве, которая уже была атакована.
Перестать давать киберпреступникам повод — по моему мнению, это главная стратегия в построении и совершенствовании корпоративного кибербеза. Начать можно с устранения часто встречающихся пробелов в безопасности. Восполнение этих пробелов и будет важным шагом с точки зрения защиты организации от атак злоумышленников.
Ошибка № 1. Нет активных средств защиты
Информационная безопасность для многих начинается с антивируса. Такой тип софта относится к активным средствам защиты. Он не только определяет зловредное ПО, но и препятствует его распространению по операционной системе компьютера, помещая в карантин либо удаляя. Проблема в том, что антивирус начинает работать в тот момент, когда вредоносное ПО уже находится внутри компьютера. Поэтому нужны и другие решения, которые затруднят или сделают невозможным сам факт проникновения.
К подобным средствам защиты можно отнести систему управления событиями информационной безопасности (SIEM), сетевые экраны с возможностью анализа пакетов данных, системы предотвращения вторжений (IPS/IDS) и др. Среди перечисленных классов решений есть как коммерческие, так и бесплатные продукты на базе ПО с открытым кодом.
Активные средства защиты позволят предотвратить такие распространенные виды атак, как брутфорс, password spraying и пр., где злоумышленник пытается активно взаимодействовать по сети с вашими сервисами. С одной стороны, для небольших компаний внедрение сложных средств типа SIEM или IPS/IDS не всегда экономически оправдано. С другой — установка утилиты вроде fail2ban для предотвращения брутфорс-атак не добавит расходов, зато легко сможет справиться с задачей блокировки IP злоумышленника.
Если есть прямые руки и время, то на базе опенсорса можно выстроить неплохую защиту. Если времени не хватает и выделяют нормальный бюджет, можно приобрести коммерческие продукты сразу с полноценной интеграцией.
Целесообразность использования тех или иных инструментов определяется набором задач и возможностями компании. Нужно определить поверхность атаки, уменьшить её до разумного минимума, а потом установить оптимальные средства защиты на те сервисы, которые ещё «торчат» наружу.
Ошибка № 2. Слабые или отсутствующие правила обработки событий
В предыдущем пункте мы акцентировали внимание именно на активных средствах защиты. Неспроста: нужно, чтобы они самостоятельно или при помощи стороннего ПО реагировали на инциденты, не дожидаясь от кого бы то ни было разрешения действовать. Для этого нужны правила, то есть зафиксированная последовательность работы всего комплекса средств информационной безопасности.
Софт из категории активных средств защиты информации предлагает ряд предустановленных правил. Это необходимый минимум, нужный для того, чтобы программное обеспечение работало «из коробки» и хоть как-то выполняло свои задачи на самых первых порах. По большому счету, основной набор правил обработки событий необходимо формулировать и добавлять по мере выявления слабых мест в своей инфраструктуре и обнаружения «тёмных пятен» — событий, которые характерны для различных атак, но в данный момент никак не описаны в правилах SIEM.
И хотя нынче формулировать правила модно при помощи машинного обучения (такая «фича» присутствует в ряде решений), этот процесс в любом случае «отпускать» не следует. Хорошим тоном будут регулярные проверки (аудиты ИБ и пентесты) — только так можно понять, насколько хороши правила обработки ИБ событий, и охватывают ли они инциденты, специфичные для установленных сервисов.
Ошибка № 3. Сомнительная парольная политика
Пароли — вот реальная головная боль для специалистов по информационной безопасности. Даже навязываемые пользователям сложные пароли не спасают. Просто потому, что юзеры начинают использовать их вне компании — например, при регистрации на сервисах заказа еды. Учитывая регулярность утечек, такие пароли оказываются скомпрометированы даже быстрее, чем приходит регламентированный срок их принудительной смены согласно ИБ-политикам компании.
Хакерам прекрасно известно о привычке пользователей применять «рабочие» пароли для учетных записей вне работы. Обычно логин для входа в корпоративную ИТ-систему совпадает с адресом почты. А уж подобрать к нему пароль из слитых записей — вопрос техники. Вероятно, благодаря этому пароли открывают дорогу 70% взломов.
Этот пробел в безопасности, вероятно, можно закрыть с помощью многофакторной аутентификации. Решения для этого есть элегантные и радикальные. К элегантным можно отнести второй фактор в телеграм-боте. К радикальным — аутентификацию по аппаратным токенам. Очень сложный пароль на 256 символов «зашит» в смарт-карте. Его не знает даже сам пользователь. А раз не знает, то и не сможет применить где-то на стороне.
Оговорюсь: бесплатных сервисов аутентификации не так много, часть из них создается энтузиастами в свободное от основной деятельности время, поэтому их тоже нужно проверять — не содержат ли они каких-либо уязвимостей. Что касается радикальных средств, то они, как правило, довольно сложны в развертывании и недёшевы с точки зрения стоимости владения. А значит, уместны к применению в организациях, где в вопросах информационной безопасности уже есть некая осознанность.
Ошибка № 4. Нет сегментации сети
Структура корпоративной сети влияет не только на связанность серверов и компьютеров организации. Она непосредственным образом сказывается на безопасности. Поэтому ограничения машрутизации соединений и постоянный мониторинг и контроль трафика между сегментами сети самым непосредственным образом влияет на защищенность от хакерских атак.
Бывает, что сегментацией пренебрегают даже весьма зрелые в айтишном отношении организации. Скажем, из песочницы, где клиент тестировал приложения open source, мы с легкостью проникли во внутреннюю сеть его инфраструктуры, захватили контроллер домена и все серверы, находящиеся в локальной сети. Клиенту повезло два раза подряд. В первый раз — что среди тестируемого в песочнице ПО не оказалось софта с вредоносным кодом. А во второй — что атаку из песочницы мы предприняли в рамках согласованного пентеста.
Сегментация сети особенно важна, если ваши сотрудники могут подключаться удалённо к своим рабочим местам или вы работаете с внешними подрядчиками. Например, вы заказали создание или доработку ПО у аутсорсинговой компании. В этой ситуации всех гостей следует держать подальше от внутреннего контура и систематически проверять, не пытаются ли они получить туда доступ.
Ошибка № 5. Нет системы резервного копирования
Решений для резервного копирования нынче много, качественный и надежный софт есть даже в опенсорсном исполнении, поэтому реализация бэкапа — исключительно вопрос технический.
Многие компании, с которыми мы сотрудничали в рамках пентестов и аудитов, честно делали ежедневные копии и хранили их в течение недели. Эти копии действительно годились для восстановления данных. Было одно «но»: все эти копии были доступны злоумышленнику по локальной сети и точно оказались бы зашифрованы в случае подобного инцидента.
Поэтому очень важно настроить сервер бэкапа таким образом, чтобы он самостоятельно подключался к источникам данных и забирал себе всю информацию, а не чтобы источники по расписанию сливали туда всё, что у них есть. С другой стороны, допустимы комбинированные решения, когда вначале все источники сливают свои данные на отдельное хранилище, потом туда подключается сервер резервного копирования и забирает к себе все файлы, после чего «рубит» соединение и становится недоступным из данного сегмента сети.
В бизнесах, где критически важно понимать «точку отката» (RPO), не помешают холодные копии данных. И, конечно, важно хранить резервные копии вне корпоративной сети. Причем в буквальном смысле. Известен пример одной аутстаф-компании, где системный администратор организовал процесс таким образом, чтобы не потерять данные даже в случае пожара или кражи сервера. Каждый день в 17:10 их система перестает принимать подключения с рабочих ПК и плавно завершает сессии, после чего выгружает все базы. К 19:00 всё наработанное за день сливается в общий архив, который записывается на магнитную ленту. Админ относит кассету с лентой в сейфовую ячейку ближайшего банка и забирает оттуда вчерашнюю катушку, на которую на следующий день записывается новая резервная копия. Так продолжается постоянно. Так что даже в наихудшем варианте потери данных его организации ограничиваются одним рабочим днем.
Искоренить выученную беспомощность
Если посмотреть на список мер, то выяснится, что реализация всего (или почти всего) перечисленного возможна относительно малыми средствами. Наличие довольно большого выбора опенсорсных решений подразумевает, что средней компании не придется вкладывать много денег в покупку лицензий. Это крайне важно, когда в организации еще отсутствует понимание, будут ли инвестиции в ИБ целесообразными.
Ну а если компания уже переживала взлом, то для оценки бизнес-смысла хорошо бы подсчитать реальные потери. Они складываются из суммы выкупа (если он был заплачен), из времени простоя, из количества человеко-часов, затраченных на восстановление, из недополученной прибыли. И — хотя институт репутации в нашей стране не особо хорошо работает, — из усилий на восстановление собственного имиджа в лице контрагентов.
Если инцидент закончится просто уплаченным выкупом, предприятия (особенно кто покрупнее) крепко подумают. В их картине мира организация, куда наведались хакеры, сама становится источником опасности. Ведь она представляет собой канал для вероятной атаки на цепочку поставок. Стоит ли связываться с таким подрядчиком, когда можно предпочесть его конкурента, у которого нет подобных проблем? Вот и получается, что вопрос обеспечения «гигиенического минимума» информационной безопасности лежит в чисто экономической плоскости. Если игнорировать этот момент, в какой-то степени можно сильно потерять в конкурентоспособности.
